perm filename SIXSYS.JAM[UP,DOC]4 blob
sn#337422 filedate 1978-02-27 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00033 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00003 00002 STANFORD UNIVERSITY COMPUTER MUSIC SYSTEM
C00006 00003 Figures
C00007 00004 OVERVIEW
C00010 00005 10/6 PROTOCOL
C00027 00006 DEVICE HANDLING OPERATIONS
C00030 00007 DAC MESSAGES
C00039 00008 ADC MESSAGES
C00045 00009 PANEL INPUT
C00054 00010 FRM MESSAGES
C00056 00011 SAM MESSAGES
C00075 00012 JOB CONTROL OPERATIONS
C00098 00013 AN EXAMPLE OF A REAL-TIME JOB
C00106 00014 SYSTEM CALLS FOR THE SIX
C00120 00015 SAIL-CALLABLE ROUTINES
C00128 00016 A SAIL PROGRAM TO READ THE PANELS
C00132 00017 RESTARTING AND RELOADING THE PDP-6
C00134 00018 THE KIM DATA COLLECTION SYSTEM
C00138 00019 KIM CABLES
C00147 00020 LOADING THE KIM PROGRAM
C00153 00021 PANEL CONNECTORS
C00160 00022 THE POT BOXES
C00164 00023 BURNDY CONNECTORS
C00167 00024 THE KIM TTY INTERFACE
C00172 00025 THE KIM PANEL INTERFACE
C00176 00026 THE KIM SERIALIZER INTERFACE
C00179 00027 THE KIM BACKPLANE
C00182 00028 THE DATA LINES
C00183 00029 OTHER HARDWARE
C00184 00030 UML - TTL IO BUS
C00193 00031 UML - TTL IO BUS EXTENSION
C00199 00032 UML DAC/ADC
C00207 00033 CABLING
C00209 ENDMK
C⊗;
STANFORD UNIVERSITY COMPUTER MUSIC SYSTEM
Usage and Maintenance
by James A. Moorer
Center for Computer Research in Music and Acoustics
Department of Music
Stanford University
Stanford, California 94305
This work was supported in part by a grant from the
National Endowment for the Arts and by
NSF contracts DCR 75-00694 and BNS 75-17715.
Figures
***A Block diagram of entire system
***B Female Burndy connector diagram
***C KIM drawings, a through r
OVERVIEW
The heart of the system is the PDP-6 computer, which operates
as a stand-alone computing system for purposes of real-time computer music
work. Connected to this computer are two digital synthesizers, digital-to-analog
and analog-to-digital converters, and a real-time console. There is a program
running on the PDP-6 computer at all times called the submonitor. It handles
the flow of information between the user and the various devices. It communicates
with the AI lab timesharing system in two ways: via disk transfers, and via a
special purpose 10/6 interface. The way things are done is that a job on the
10 (the regular timesharing system, sometimes referred to as the KL10)
communicates with the submonitor by sending
it messages through the 10/6 interface. These messages direct the submonitor to
initiate transfers to or from its various devices. In addition, the submonitor can
run a single user job, which can directly get at these devices. This job runs
continuously without interruption and is thus ideal for real-time computation.
In addition, there is a data collection system under the control of a microprocessor
called the KIM. This allows various different kinds of input devices, such as
organ keyboards and potentiometers, to be read by the PDP-6, and thusly in turn
by the KL10.
Figure ***A shows a schematic diagram of the entire system. Each subsystem
will be discussed in turn.
To the average music user, the actual contortions the system goes through
for your commands is not entirely relevant except in certain cases. For
the advanced user, however, who wishes to write special programs for
operating the system, he will have to learn the different parts of the
system and how they interact.
10/6 PROTOCOL
The 10 and the 6 exchange messages with specific formats that control
the various functions of the 6. Very little validity checking is done
on these messages, so that it is not difficult to kill the 6 submonitor.
It is much harder to kill the 10. The messages look roughly like this:
Each message has a 1 or 2 word header.
WORD 1
BITS PATTERN NAME INTERPRETATION
---------------------------------------------------------------------------
0 400000,,0 F6TO10 Direction code. If on, means this is a message
from the 6 to the KL
1 200000,,0 FNOWDS Means that this is a 1-word message only
2 100000,,0 FNCOMP Message is incomplete for some reason (hardware?)
3 040000,,0 FDMISSED Data was missed on this message, may be incomplete.
4:5 030000,,0 Currently unused
6:17 007777,,0 Message type code.
18:26 0,,777000 Job number of source (10→6) or destination (6→10)
of message. PDP-6 real-time job is job 400.
27:35 0,,000777 Device number of source (6→10) or destination (10→6)
of message. PDP-6 submonitor is device 0.
WORD 2
BITS PATTERN NAME INTERPRETATION
---------------------------------------------------------------------------
0:17 777777,,0 Number of data words in message (following this word)
18 0,,400000 Means this message was originated on the 6 (rather than
just being a reply to a message from the 10)
19:35 0,,377777 Sequence number of this message.
Following the 2-word header, there will be the number of words specified by the
left half of the second word of the header (if any).
WD 1 <flags*10000+type code>,,<job number*1000 + device number>
WD 2 <Nwords>,,<sequence number>
WD 3 Nwords consecutive data words
Messages from KL to 6 are distinguished from messages from 6 to KL by
the message type code. With 6→KL, the high-order bit (400000) is
always on. Most of the messages from the 6 to the KL are responses
to previous messages from the KL to the 6. In this case, the reply
message has the same sequence number as the original message. The 6
can also originate messages, in which case it turns on the 400000 bit
of the sequence number to indicate an original message. If the KL
replies to this message, it repeats the sequence number.
The 200000 bit in the type code indicates this is a 1-wd message.
High-order 6 bits of WD 1 are flag bits of various kinds.
The first 1000 (octal) message codes are reserved for "system" type
messages that are valid on any "device". Since these messages are
only valid in one direction, the replies have the same message codes.
Some of these things pass word counts and memory addresses back
and forth. In each case, a WCMA is passed, NOT an IOWD! That is,
XWD -<word count>,<memory address>.
There are a series of error codes that can be returned. Generally,
when an error is indicated, the type code and the sequence number
match those of the ailing message.
Here are the error codes that may be returned from the six system:
CODE NAME DESCRIPTION
---------------------------------------------------------------------------
1 ENOJ Operation on job attempted when no job was initialized
2 ENOD This message required a datum and none was sent
3 ENOJC From MJINI, means "Can't get 1K core for job"
4 ECNTC From MCONTJ, means "Can't continue" (job in ERRQ)
5 ENOB From MGIVB, means "No such buffer"
6 (Currently undefined)
7 EWCR From MWMEM, means "Word count longer than message"
10 EOOB From MWMEM, means "Addresses out of bounds"
11 ENOWC From MRMEM, means "Zero word count"
12 ENOFS From MRMEM, means "Not enough F.S. to do this transfer"
13 ENED Means "not enough data in this message"
Note: A message can always be longer than necessary. Quite often in the 6
submonitor the same routine is used to transmit messages that do or do not
return data, thus a message that you might think should only be one word
(like MIAA below) might actually be a 3-word message, although the last two
words won't carry any extra information. You should distinguish messages
on the basis of the type code, not on the basis of the length.
Mnemonic: MRST Reset
Type code: 0
Datum: none
Reply: MRST with no datum
This causes the 6 submonitor to reinitialize itself completely. It forgets
anything it may have known about what jobs on the KL may have been doing
on the 6. It is a quite drastic step and should not be done unless you know
what you are doing. This command is normally sent out by the regular timesharing
monitor when the system is reloaded. The 6 submonitor responds by asking for
the time and date (after reinitializing itself).
Mnemonic: MAYA Are you alive?
Type code: 1
Datum: none
Reply: MIAA, I am alive
This is a quick test to see if the 6 system is alive at all. You should
get back very shortly a MIAA message.
Mnemonic: MIAA I am alive
Type code: 2
Datum: zero
This is the reply to the MAYA code. It will not be generated spontaneously.
Mnemonic: MRMEM Read memory
Type code: 5
Datum: WCMA to read from
Reply: Success → WCMA+data, Failure → ENOWC, EOOB, ENOFS
Reads data anywhere in the 6 core. The only check is to make sure that
the memory requested is not out of the bounds of the physical memory.
You can read the system itself with this operation. You send a WCMA
of the data in the 6 core that you want to read. On success, it returns
you that WCMA, followed by that many words. Upon failure, it returns
one of the error codes ENOWC, EOOB, or ENOFS. ENOWC means your message
as received didn't have a WCMA in it. EOOB means that the WCMA referred
to memory that was not part of the physical memory of the 6. ENOFS means
that we don't have enough F.S. to copy this data into to send it to you.
Mnemonic: MWMEM Write memory
Type code: 6
Datum: WCMA+data
Reply: Success → 0, Failure → EOOB, EWCR
Write data in the 6 memory. Message consists of the WCMA of the area
to write in followed immediately by that much data. If you don't send
as much data as specified in the WCMA, you get the EWCR error. If you
try to deposit into the monitor itself, or above physical memory, you
get the EOOB error. Zero is returned upon success.
Mnemonic: MHMFC How much free core?
Type code: 7
Datum: none
Reply: Number of words of free core
This finds out how much free core there is in the 6 memory, that has
not already been allocated either to free storage (where buffers
come from) or to the real-time job. It does not tell you how much unused
room free storage has due to checkerboarding.
Mnemonic: MMERR Memory error in 6 (Currently not generated)
Type code: 10
Datum: (not defined yet)
This code may at some point in the future be enabled to tell the KL user
about PDP-6 parity errors. It will probably return the absolute address
of the error, the data, and the PC at that time. Currently this code
is not generated.
Mnemonic: MNON Nonsense, 6→KL
Type code: 11
Datum: none
The 6 returns this code if it can't make any sense out of the last command
sent.
Mnemonic: MECC Error Correction code data, KL→6
Type code: 13
Data: ECC word pairs from the disk service
This code is for making the error corrections to data read from the disk
into the 6 memory. The format for these words is described elsewhere. The
data is the list of ECC pairs exactly as they come from the disk service.
There should be an even number of words in the data.
Mnemonic: MTIME Time of day
Type code: 14
Data: Date and time
If you receive this message from the 6, it is asking for the time and date.
You should send it back the same code with the date as the first datum
and the time as the second datum. You can send it the time and date at
any point. It will update the 6 system's idea of the time and date.
Mnemonic: MCLRJOB Clear job, KL→6
Type code: 16
Datum: none
This clears everything the 6 system knows about the KL job whose number
is in the message header. It blasts all the devices that job had
initialized, it clears the real-time job if it belonged to this KL job,
and it releases any buffers that job may have had. This goes out when
you release the device SIX.
Mnemonic: MDBLAST Blast device, KL→6
Type code: 33
Datum: none
This takes the device code in your message and blasts that device. That
releases any buffers associated with the device, it stops the device
amid-transfer if it is running, and so on. If two different devices
are using the same buffer, there may be a conflict here.
Mnemonic: MGBUF Get Buffer, KL→6
Type code: 17
Datum: Number of Words
Reply: Success → WCMA, Failure → Free core
This claims a length of contiguous free core in the PDP-6 memory. The
success reply is the WCMA of the buffer claimed. Your job number is
associated with this buffer so that if you release the SIX device, these
buffers will go away. If there is not enough free storage to give you the
buffer, the reply is the number of words of free core (a positive number).
A WCMA is minus the number of words in the left half and the absolute
core address of the first word of the buffer in the right half (not to
be confused with an IOWD!).
Mnemonic: MGIVB Release Buffer, KL→6
Type code: 20
Datum: Address of first word of buffer
Reply: Success → 0, Failure → ENOB (=5)
This releases a buffer. It returns 0 upon sucess and the ENOB error if
it has no record of such a buffer. This might happen if the PDP-6 got reloaded
or restarted out from under you.
There are various hazards involved with buffers. For instance, no checking
is done to see if some device (like the DAC or the ADC) is running in a current
buffer before it is released. Thusly, you should be very sure to kill the
device, or to make sure you got a "buffer done" reply before you release
the buffer.
Mnemonic: MLP Loop data
Type code: 21
Datum: Whatever you wish
Reply: MLPR message with a copy of that data
This is a test op to make sure the PDP-6 system is functioning. It just
sends the data to the 6 and receives it back.
Mnemonic: MLPR Loop data return
Type code: 22
Datum: Copy of data in previous MLP message
Reply: none
This is the reply operation to the previous op.
Mnemonic: MAUTOL Automatic reload, KL→6
Type code: 36
Datum: none
Reply: none
This causes the PDP-6 system to load itself into the accumulators and
start counting down. When it reaches zero, it jumps to 200 and restarts
itself. This is what SIXFIX uses to reload the system.
DEVICE HANDLING OPERATIONS
The six system identifies the IO devices that are connected to it by
numbers. These are as follows:
NUMBER NAME DESCRIPTION
---------------------------------------------------------------------------
0 SYSDEV PDP-6 submonitor itself
1 SAMDEV Systems Concepts Digital Synthesizer
2 DACDEV DA converter
3 ADCDEV AD converter
4 FRMDEV Dick Moore's digital synthesizer
5 KIMDEV Paralyser panel (real-time console) interface
6 RTJDEV Real-time job on the 6
When you send a message that is intended for a specific device (type code
over 1000), then that device number should be included in the header. If
you send a system message (type code less than 1000), the device field in
the header then refers to the device this command is for. For instance,
if you claim some buffers for the DAC, you ought to put DACDEV in the device
field. That will associate that device with the buffer, so that if you give
a MDBLAST to clear out the device, that buffer will be released also.
Your job number is associated with a device the first time you send a message
to a device (type code greater than 1000). It is cleared with either a
device blast (MDBLAST) or a MCLRJOB message.
Since messages for each device are pretty different, they will be described
separately.
Note: since there is no interlocking on the 6, it is possible for two jobs
to send messages to the same device. To prevent this unplesant possibility,
there are six dummy devices on the KL, entitled SAM, DAC, ADC, FRM, KIM,
and RTJ. On the KL, these devices do not do anything, but you can INIT
them and RELEASE them. This goes through the standard system device wait
business, so only one job at a time can INIT them. These should be used
only to reserve the devices. Any INPUT or OUTPUT to these dummy devices
on the KL will result in an error.
DAC MESSAGES
In general, the way you operate the DAC is to first get some number
of buffers (at least 3), dump some data in them (presumably through
the disk, though not necessarily), set the DAC speed and packing,
then start the buffers. Each time a "buffer done" message comes in,
you can refill the buffer and start it again. The "buffer done" message
does not carry a datum saying what buffer it was that just got done, so
you have to remember the order in which you sent the start commands out.
P.S. - there is a queue of buffer start commands, so that if the DAC is
already running, these commands just stack up. Thusly, you can go ahead
and stuff all the commands you will ever need into the queue, and just
hope that you can keep up with it if you can.
Mnemonic: MSPAR Set parameters
Type code: 1010
Datum: speed*1000 + pack*100 + Nchannels
Reply: Success → Cono word itself, Failure → -1
This sets the speed, packing mode, and number of channels for the DAC.
The speed is a 3-bit field in bits 24:26. The packing mode is a 2-bit
number in bits 28:29. The number of channels is a 2-bit number in
bits 34:35. All other bits in the datum are ignored at this time,
but nonetheless should be set to zero in case we decide to do something
with them. The various fields are decoded as follows:
NUMBER PACK SPEED NCHANNELS
--------------------------------------
0 12-Bit 6.4 Kc Quad
1 18-Bit 12.8 Kc Mono
2 9-Bit 25.6 Kc Stereo
3 12-Bit 51.2 Kc Quad
4 102.4 Kc
5 204.8 Kc
Mnemonic: MSTBUF Start buffer
Type code: 1011
Datum: WCMA of buffer to start
Reply: Returns WCMA when buffer actually started
If the DAC is already running, the buffer will be queued, and
you will not receive the reply until it is actually taken out
of the queue and started.
Mnemonic: MSTOP Stop everything
Type code: 1012
Datum: none
Reply: always returns 0
This halts the DAC, clears the queue of pending transfers. It does
not release any buffers, just stops the dac and clears the queue.
Mnemonic: MQBUF Queue buffer
Type code: 1013
Datum: WCMA of buffer to queue
Reply: Returns MSTBUF command when started
This is for simultaneously starting the DAC and the ADC. You first
queue up a bunch of buffers on the DAC using this message. This
operation records the WCMAs you send it, but does not actually start the
device running. When you are ready to start the device, there is a message
to the ADC that will start them both.
Mnemonic: MFSTB First buffer coming
Type code: 1015
Datum: none
Reply: none
This clears the internal "buffer done" count. It should be given at the
beginning of a distinct transfer. The point is that the 6 counts the
number of times that it runs off the end of a buffer without having another
buffer sitting there ready to go. This can mean one of two things: either
a long transfer has been entirely completed normally, or the disk couldn't
keep up with the DAC and a buffer has been missed. If you start another
buffer and this "buffer done" count is non-zero, the 6 will return the
MBMISS message to you. If you want to play the sound file several times,
but don't want the message in between, you should give this message before
each time you play it to clear out the buffer count.
The following are messages that the DAC code will generate spontaneously
(sort of).
Mnemonic: MBDONE Buffer done
Type code: 1020
Datum: none
Reply: none
When the DAC has finished with a buffer, this message is sent out. It
does not identify the buffer, but since they are processed in the order
you start them in, they will be finished in that order too.
Mnemonic: MHUNG Device hung
Type code: 1021
Datum: none
Reply: none
This message is sent when the DAC took 2 seconds longer on a particular
transfer than it should have. This generally means that the DAC is
somehow hung up (hardware?). The next transfer in the queue is started.
This message should be considered like a MBDONE message (in some sense!),
in that you will not get a MBDONE message for this buffer. It does not
abort all succeeding transfers, but instead it tries them one after
another.
Mnemonic: MDMISS Data missed (hardware detected)
Type code: 1022
Datum: number of times data missed seen
Reply: none
This means that the hardware detected a data missed condition. This
usually means that the PDP-6 itself could not respond fast enough
to shovel out the next word full of samples. This can occur if there
is any higher priority device running (like the systems concepts
digital synthesizer) that used up a lot of time and causes us to
miss an interrupt. It will sometimes make pops in the music, but not
necessarily. It still might sound just fine.
Mnemonic: MBMISS Buffer missed (software detected)
Type code: 1023
Datum: number of buffers missed
Reply: none
This message is generated after a MBDONE and a MSTBUF message, indicating
that the next buffer was not started in time after the previous one
to assure a continuous transfer. This one will make real pops in the
sound invariably.
Mnemonic: MBOOB Buffer address out of bounds
Type code: 1025
Datum: WCMA of offending xfr
Reply: none
If your WCMA specifies a transfer that either starts of ends outside
of memory, then you get this message back. The transfer will be
aborted.
ADC MESSAGES
The ADC is worked almost exactly the same way the DAC is worked,
except in the opposite direction. You set up some buffers (3 or more),
set parameters with a MSPAR message (same format as for the DAC except
that the maximum overall sampling rate is 51.2 KHz and 9-bit FPI mode
is illegal), then you start the ADC running with MSTBUF messages. Each
time you get a MBDONE message, another buffer has been filled and can
be transferred to the disk. The MHUNG, MDMISS, and MBMISS message mean
the same things as with the DAC. The MFSTB message, like for the DAC,
zeros the buffer done count. In addition, there are several new and unusual
messages that are especially for the ADC. There are also some small differences
in the parameters word (MSPAR message), in that the left half of the word
is also decoded.
Mnemonic: MSPAR Set parameters
Type code: 1010
Datum: (thresh + mpx),,(speed*1000 + pack*100 + Nchannels)
Reply: Success → Cono word itself, Failure → -1
This sets the speed, packing mode, and number of channels for the ADC.
The speed is a 3-bit field in bits 24:26. The packing mode is a 2-bit
number in bits 28:29. The number of channels is a 2-bit number in
bits 34:35. The threshhold for recycle mode is set from bits 0:16 (see
MSTRCY message below). Bit 17 is taken to be the input multiplexor setting.
0 is normal, 1 means alternate inputs. This refers to the second row of
phono jacks on the ADC itself in the machine room.
Mnemonic: MSTRCY Start buffer in recycle mode
Type code: 1013
Datum: WCMA of buffer to start
Reply: Returns WCMA when buffer actually started
This starts this buffer all right, just like any other MSTBUF message,
but if the threshhold is nonzero, which is set from the MSPAR message,
then the ADC will be arranged to go back to the beginning of this
buffer again and again if the signal does not exceed the threshhold. As
soon as the signal exceeds the threshhold, you will get a MRCYDN
message back with the position in the buffer when the threshhold was
exceeded, and the ADC will move on to the next buffer just like usual.
From this point on through the duration of the transfer, regardless of
how many more bufferfuls are required, operation will be normal. This
recycling business applies only to the first buffer full. The only
curiosity about this is that if there are no further buffers, you
will not get an MRCYDN message back.
Mnemonic: MRCYDN Recycling done, 6→KL
Type code: 1024
Datum: IOWD of last word read into buffer
Reply: none
This returns the IOWD that the system used to haul in the last word
of the recycle buffer when the threshhold was exceeded. In other
words, the right half of the datum is the absolute address in 6
memory of the word that exceeded the threshhold. You will have to
unravel the buffer yourself.
Mnemonic: MSTSIM Start buffer, simul-start DAC
Type code: 1014
Datum: WCMA of buffer
Reply: MSTBUF back with WCMA of buffer started
If you have queued up a bunch of buffers on the DAC with the MQBUF message
instead of the MSTBUF message, then the DAC is just sitting there, loaded
and cocked, but not running. This message will start an ADC buffer, just
like MSTBUF does, but will also call the DAC routines to start the DAC at
exactly the same moment. Actually, you can expect up to a several sample
delay due to pipelining of the DAC and ADC hardware, but it will be within
a few hundred microseconds of being simultaneous.
PANEL INPUT
The KIM listens to regular terminal keyboards and to the real-time input
devices (herein referred to as "panels"), and forwards messages to either
the 6 or the KL which tell what has changed or when. There is a physical
hardware interface both on the KL and on the 6. The KIM sends a 32-bit
datum out which has an 8-bit header that identifies the destination
computer. Thus the software on the KIM can decide what data to send
where and what format it should be. The software is currently arranged
to send panel data to the 6 and terminal keyboard data to the KL. The
terminals that are connected through the KIM to the KL should be
indistinguishable in every way from any other terminal keyboards, thus
any of the standard system UUOs can be used to read these keyboards.
As for the panels, that is a bit more tricky to receive.
The 6 keeps two tables of length 128 each. The first of which is
an image of all the bytes on all the panels (16 panels by 8 bytes
each makes 128. Right?). The KIM is programmed to send a datum
to the 6 each time one of the 8-bit bytes in the panels changes. It
then sends a coded datum that says what byte changed and the new value.
This code is stored in the 128-word table in the 6 along with the
time in 60ths of a second since midnight in the other table. To start
receiving data from the KIM, you can send the 6 a message that says
"start sending". Thereafter, when a datum comes in from the KIM, it
will not only store it in its internal table, but it will send you
a message with that datum and the time that it came in also.
You can get a copy of the table also, so that you can know what state
things were in when the changes started coming in.
The data are coded as follows:
BITS PATTERN NAME INTERPRETATION
---------------------------------------------------------------------------
0 400000,,0 DNEW This bit is on if this is "old" data and
an incremental update on this byte has
not been sent to the KL yet.
1:11 377700,,0 Unused. Will be zero.
12 40,,0 DMBIT Data missed detected by the KIM
(means 6 did not eat the last datum in time)
13:16 36,,0 PANNO 4-bit number for the panel number
17:19 1,,600000 BYTNO 3-bit number for the byte within that panel
20:24 174000 PANID 5-bit number saying which physical panel it is
25:27 3400 PANTYP 3-bit number for the type of this panel
28:35 377 DATUM 8-bit data byte
The DNEW bit is turned on when a datum comes into the 6 and no job on the KL
has asked for panel input. Thusly, you only see this bit if you read the
entire panel state from the KIM. You will never see it on a regular
update message.
The DMBIT is generated by the KIM when it tries to send an update byte
to the 6 and the 6 is not ready for it (there is a line back to the KIM
that says "6 ready"). In this case, the update byte is lost, and the
next message the KIM sends to the 6 that gets through will have this
bit on in the datum.
The 4-bit PANNO is which EIA connector the panel is plugged into. There
are 16 of these sockets. The 3-bit BYTNO is which of the 8-bit bytes on
that panel we have read. The PANID number is 5-bits long and is different
from the PANNO number. PANID is the number of the physical input device
regardless of what socket it is plugged into. This number is wired in when
the panel device is built. The PANTYP number is also wired in and tells
what kind of panel this is. There are currently two nontrivial types. Type
0 means nothing is plugged in here. Type 1 is a kind of switch panel, such
as a Klavier (organ keyboard). Type 2 is a pot box (analog data). The 8-bit
combination of the PANID and the PANTYP form a unique number for
each physical input device.
Mnemonic: MSEND Start transmitting panel data (KL→6)
Type code: 1011
Datum: none
Reply: none
This starts the 6 sending panel changes to you. The datum is really your
job number which is inserted in the message header by the system.
Mnemonic: MSTOP Stop transmitting panel data (KL→6)
Type code: 1012
Datum: none
Reply: none
This stops the 6 sending panel changes to you. The datum is really your
job number which is inserted in the message header by the system.
This will happen automatically when your KL job CLOSEs the device SIX.
Mnemonic: MSTATE Get entire state of KIM panels
Type code: 1013
Datum: none
Reply: message containing state
The 6 sends you a message back of length 256 data words. The first 128 words
are the state of the panel bytes (in the same format as above) and the
next 128 words are the times that these changes were recorded.
Mnemonic: MNEWD New datum, 6→KL
Type code: 1010
Datum: 2 words, data byte and time
Reply: none
After you send a MSEND message, the 6 will start sending you back these
messages. Each message has two data words, the first of which is the
panel update byte (in the above mentioned format) and the second of which
is the time the datum came into the 6 in 60ths of a second after midnight.
(yes, you get a wraparound to 0 at midnight!).
FRM MESSAGES
This code does not exist yet, so there is not much point in writing
about it.
; MESSAGES RECEIVED
MPLAY←←1010 ; SEND THIS DATA NOW
MSTBUF←←1011 ; START PLAYING THIS BUFFER
MSTOP←←1012 ; STOP PLAYING, KILL
;MESSAGES SENT
MBDONE←←1020 ; BUFFER DONE
MBMISS←←1023 ; NEW BUFFER NOT SENT IN TIME
MBOOB←←1025 ; BUFFER OUT OF BOUNDS
MBADB←←1026 ; EVENT RAN OFF END OF BUFFER
Mnemonic: MPLAY Start buffer
Type code: 1011
Datum: WCMA of buffer to start
Reply: Returns MBDONE when buffer actually started
This will DATAO all of the words specified by the WCMA to the
FRMbox.
SAM MESSAGES
The Systems Concepts digital synthesizer is a very hairy beast indeed. For
this reason, we shall not attempt to describe it here, but will refer the
interested reader to LRNSAM.DGL[UP,DOC].
The synthesizer has three major data streams: read data, write data, and
commands. Each one of these streams has a separate "start buffer" message.
Linking buffers together is done by the 6 system software all automatically
without your ever knowing it. It will intercept the appropriate interrupts
and issue the appropriate DATAOs to keep the device going as best it can.
The synthesizer is on the highest priority interrupt channel on the 6,
thus it can interrupt the DAC, the ADC, or any other 6 device.
In the following, WC stands for word count and MA stands for memory
address.
In general, the way you operate the device is to deliver CONOs to set up
the condition of the machine, send WCMAs to set up the data stream addresses,
then start the clock with a CONO-A. In general, the way to cold-start
the device is to send a CONO-A to do a master reset and make all ticks
update ticks. You can then send a buffer full of commands that would
presumably have some kind of initialization, like setting all the generator
modes to zero. You start the device with a CONO-A to start the clock.
Then to actually start running, you send it another command list, allow
processing ticks, and away you go. You can use the CONO-B to allow stop
or interrupt on various different conditions. You will just get these
back as MINT messages.
The software will take care of fielding the "WCMA exhausted" interrupts.
Excess "start buffer" messages will just be queued, so that when an
"exhausted" interrupt comes in, the next WCMA can be DATAOed out immediately
without delay. It doesn't make sense to have any more than three buffers
of each flavor at any given time.
Mnemonic: MCONOA Send CONO-A to the device
Type code: 1010
Datum: cono bits
Reply: none
This immediately CONOs the datum word to the device. It does not, however,
let you set PIs. This will be done by the system software for you, so those
bits (A and B below) are irrelevant to you.
CONO-A BITS
BITS PATTERN NAME INTERPRETATION
---------------------------------------------------------------------------------
18:19 600000 CC Clock control, 0=no effect, 1=stop clock,
2=start clock, 3=cause one tick
20 100000 T Reset tick counter to beginning of pass
(only if stopped)
21 040000 A 1=no effect, 0=reset interrupt channel A from PIA
22 020000 B 1=no effect, 0=reset interrupt channel B from PIA
23:24 014000 NN Tick control: 0=no effect, 1=permit processing
ticks, 2=all ticks update (inhibit processing
ticks)
25:31 003760 DD Diagnostic readback address. Specifies internal
data to be read by DATAI-A
32 000010 MR Master reset (clears PIA channels, interrupt
enablings, etc)
33:35 000007 PIA Interrupt channel assignment
Mnemonic: MCONIA Give me CONI-A
Type code: 1021
Datum: none
Reply: coni-A bits
This asks for a direct reading of CONI-A. This operation is not really that
useful, in that you will get spontaneous CONI-As back with the MINT message
when they occur. This is useful, I suppose, for finding out whether the
synthesizer is running or not.
CONI-A BITS
BITS PATTERN NAME INTERPRETATION
---------------------------------------------------------------------------
16 2,,0 AR Interrupt desired on channel A
17 1,,0 BR Interrupt desired on channel B
18 400000 IR Interrupt desired by ME, PE, MX, WU, RU,
CU, WE, RE, or CE
19 200000 CE Command WC exhausted
20 100000 WE Write data WC exhausted
21 040000 RE Read data WC exhausted
22 020000 ME Parity error detected in delay memory
23 010000 PE Parity error during direct memory access
24 004000 NX Non-ex mem (PE and NX suppress further memory
access until reset by CONO-B)
25 002000 R Running (not stopped)
26 001000 NH Not held (like R but off while clock stopped
for direct memory access)
27 000400 CU Command data underrun (cleared by CONI-A)
28 000200 WU Write data underrun (cleared by CONI-A)
29 000100 RU Read data underrun, (cleared by CONI-A)
30:32 000070 PIAA A (high priority) interrupt channel assignment
33:35 000007 PIAB B (low priority) interrupt channel assignment
Mnemonic: MCONOB Send CONO-B to the device
Type code: 1011
Datum: cono bits
Reply: none
This does a CONO-B to the device immediately. It also decodes your
CONO word to tell what interrupts you are enabling or disabling. The
6 software then prepares from that a mask for the CONI-B word so it
can tell when we get an interrupt that we are interested in.
CONO-B BITS
BITS PATTERN NAME INTERPRETATION
---------------------------------------------------------------------------
29:30 000140 ZZ Memory error reset control: 0=no effect,
1=reset ME error, 2=reset PE and NX
errors, 3=reset ME, PE, and NX errors
31:32 000030 BB (Decoded with AAA)
00AAA=Disable stop on cause AAA
10AAA=Enable stop on cause AAA
01AAA=Disable interrupt on cause AAA
11AAA=Enable interrupt on cause AAA
AAA=001 → Command overrun (I1)
AAA=010 → Modifier mixer overflow (I2)
AAA=011 → Modifier multiplier overflow (I3)
AAA=100 → Modifier add to sum overflow (I4)
AAA=101 → Generator add to sum overflow (I5)
00110=Disable interrupt on write data WC exhausted
10110=Enable interrupt on write data WC exhausted
01110=Disable interrupt on read data WC exhausted
11110=Enable interrupt on read data WC exhausted
01000=Disable interrupt on command WC exhausted
11000=Enable interrupt on command WC exhausted
00111=Indicate 16-bit read data
10111=Indicate 32-bit read data
33:35 000007 AAA
Mnemonic: MCONIB Give me CONI-B
Type code: 1022
Datum: none
Reply: coni-B bits
This does a CONI-B immediately and sends you the word back. Again, this
message is probably not so useful, in that any spontaneous interrupts
will produce an MINT message.
CONI-B BITS
BITS PATTERN NAME INTERPRETATION
---------------------------------------------------------------------------
20 100000 I1 Command overrun
21 040000 I2 Modifier mixer overflow
22 020000 I3 Modifier multiplier overflow
23 010000 I4 Modifier add to sum overflow
24 004000 I5 Generator add to sum overflow
26 001000 LC Lost cause
27:35 000777 Tick number when cause occurred
Mnemonic: MINT Condition interrupt from A or B channel
Type code: 1100 6→KL
Datum: CONI-A with bit 0 on, or CONI-B with bit 1 on
Reply: none
If spontaneous interrupts (that you have enabled for with the CONOA or
CONOB commands) occur, they are reported to you with this message. There
will be a high order bit on in the return datum indicating which channel
interrupted. 400000 bit in the left half (bit 0) indicates CONI-A. The
200000 bit in the left half (bit 1) indicates CONI-B.
These bits have names:
BITS PATTERN NAME INTERPRETATION
---------------------------------------------------------------------------------
0 400000,,0 CABIT This datum is a CONI-A
1 200000,,0 CBBIT This datum is a CONI-B
When an interrupt comes in, it is compared with the mask that has been
set from previous CONOB instructions. Certain errors (like CONI-A errors)
are unmasked and generate messages regardless. If the bit shows through the
mask, this message is generated. There is in fact a queue of some number
of CONIs. They are placed in this queue at interrupt level, and are removed
at clock level to produce these return messages, which leads us neatly to
the next message:
Mnemonic: MIOV Too many condition interrupts, 6→KL
Type code: 1101
Datum: CABIT,CBBIT, and/or how many interrupts were lost
This message means that too many CONI-A or CONI-B interrupts were generated
and the software queue overflowed. This would have to be a lot of interrupts,
because the queue is emptied every 60th of a second. If CABIT is on then there
were so many memory errors that the box's clock was stopped. Likewise if CBBIT
is on then there were so many overflow/overrun interrupts that it was necessary
to disable further such interrupts. Otherwise the interrupt queue overflowed,
but no harm was done.
Mnemonic: MWDBUF Start write data buffer
Type code: 1012
Datum: WCMA of buffer
Reply: 0 for success
This specifies a buffer for write data. The word count and memory
address will be DATAOed out immediately for the first buffer. Successive
buffers will be queued, awaiting the "WC exhausted" interrupt.
Mnemonic: MRDBUF Start read data buffer
Type code: 1013
Datum: WCMA of buffer
Reply: 0 for success
Same deal for read data.
Mnemonic: MCBUF Start command buffer
Type code: 1014
Datum: WCMA of buffer
Reply: 0 for success
Same deal for commands. Note that none of these operations starts the
clock for you. You must do that yourself with a CONO-A operation.
Mnemonic: MWDONE Write data buffer done, 6→KL
Type code: 1102
Datum: none
Reply: none
Each time a write data buffer gets done, one of these messages is
returned. They are processed in order.
Mnemonic: MRDONE Read data buffer done, 6→KL
Type code: 1103
Datum: none
Reply: none
Each time a read data buffer gets done, one of these messages is returned.
They are processed in order.
Mnemonic: MCDONE Command buffer done, 6→KL
Type code: 1104
Datum: none
Reply: none
Each time a command buffer gets done, one of these messages is returned.
They are processed in order.
Mnemonic: MDTA DATAO-A, perform command
Type code: 1015
Datum: Command word
Reply: 0 for success
This blindly DATAO-As the datum you send. This is one way to do things
like set number of processing and update ticks before running a program.
If you do this while the clock is stopped, you have to tick the clock
once for each command you do.
Mnemonic: MDTC DATAO-C, set diagnostic write buffer data
Type code: 1016
Datum: Write buffer word
Reply: 0 for success
This is a diagnostic operation. It sets the diagnostic write buffer data
register from the datum of the message with a DATAO-C.
Mnemonic: MDTIA DATAI-A, diagnostic readback
Type code: 1023
Datum: none
Reply: readback word
This returns the diagnostic readback word to you. It does a DATAI-A to
get this word.
Mnemonic: MDMWR Write data into delay memory
Type code: 1017
Datum: WCMA+data
Reply: none
The WCMA is the address in delay memory (from zero to 48K-1). The count is
the number of words. The following data is assumed to be right-adjusted
20-bit two's-complement integers. They are taken and massaged into the
proper format. If the address falls out of bounds, that word is not deposited.
Mnemonic: MDMRW Write data into and read from delay memory
Type code: 1020
Datum: WCMA+data
Reply: WCMA+data
There is no way to directly read the delay memory non-destructively
(without using the diagnostic features, I suppose). This message causes
the right-adjusted 20-bit integer data to be written in the delay memory,
and the overwritten data (also right-adjusted 20-bit integers) to be sent
back to the user. If the address gets out of bounds, the original data in
the message is returned.
Mnemonic: MDMZ Zero part of delay memory
Type code: 1024
Datum: WCMA
Reply: none
Clears part of delay memory.
Mnemonic: MSTIFL Inactivate processing elements
Type code: 1025
Datum: none
Reply: none
Set all generators, modifiers, and delay units to inactive mode.
JOB CONTROL OPERATIONS
A KL job can initiate and control a single job on the 6. This job communicates
with the KL job via messages. There are certain system messages for starting,
stopping, and error control of the job that are described below. When you initialize
the real-time job, it claims 1K of core. Core allocation is in terms of
integral numbers of K. The job can be in one of 5 states, or "queues".
QUEUE NAME MEANING
---------------------------------------------------------------------------
0 NULLQ Job not initialized
1 RUNQ Job is running
2 IOWQ Job is waiting for a message
3 ERRQ Job has been stopped fatally (error or initialization)
4 STOPQ Job stopped "softly", can be continued
The real-time job communicates with the 6 system itself by messages. These
messages are essentially indistinguishable from messages from the KL,
except that they are from job number 400. (Job numbers on the KL only go
up to 77). The mnemonic for this is OURJN. Likewise, messages from a
device to a job number 400 are intercepted and forwarded to the real-time
job (rather than the KL). In this way, the job can do anything that a KL
job can do. The real-time job has three monitor calls with which to send
messages, receive messages, and find out information (like whether there
are any messages waiting). There are the following messages to the 6
system for controlling jobs. For all messages except MJINI, you can get a
reply with a datum that says ENOJ, or "no job initialized". For instance,
you will get that reply if you ask to start or stop the real-time job and
there is no job initialized.
If the RTJ goes bad somehow (ill. UUO or something), you will get an error
message back from the 6 system (device 0).
Mnemonic: MJINI Initialize real-time job
Type code: 23
Datum: none
Reply: Success → 0, Failure → ENOJC (no core for job)
Initialize the real-time job. If any real-time job was already initialized,
it is flushed, even if it belongs to a different KL job than your own. No
interlocking is done. To initialize the job, it is placed in ERRQ (can't
continue state), and given 1K of memory.
Mnemonic: MJCORE Get core for real-time job
Type code: 24
Datum: Highest desired address for job
Reply: Success → WCMA of job, Failure → available words
This does core allocation for the real-time job. Core is allocated contiguously.
The system cannot move the job to any other place in memory, so once you learn
the address of the job, it will always be there, though its length may
change. This is the only message for job control that deals in absolute addresses.
All the others (like MSTJOB) deal in relative addresses, relative to the
origin address of the job.
Mnemonic: MSTJOB Start job
Type code: 25
Datum: PC word where job is to be started
Reply: Success → 0, Failure → ENOJ (no job initialized)
The job is started at the PC given. The user-mode bit is ORed into the
left half of the PC word before starting. If you want the job to be in
iot-user mode, then simply turn that bit on in the left half. Likewise
for the flags.
Mnemonic: MJHALT Stop job softly
Type code: 26
Datum: none
Reply: Failure → 0, Success → Old queue in RH, PC in LH
The job is stopped and placed in STOPQ. The old queue code is returned
in the right half of the datum, the stopped PC in the left half. The
job can be continued by a MCONTJ operation. If the job was in ERRQ, the
queue is not changed (still can't continue it).
Mnemonic: MFLUSJ Kill job entirely
Type code: 27
Datum: none
Reply: Success → 0
This de-initializes the job. It releases all core associated with the job,
it releases any buffers the job has claimed, and clears any devices the
job might have been using. After this, the job is not initialized, and
an MJINI would have to be done to do anything further to the job.
Mnemonic: MCONTJ Continue job
Type code: 30
Datum: none
Reply: Success → old PC, Failure → Old queue,,ECNTC
If the job is in STOPQ, which it can only get into if you send it a MJHALT
message, or if it executes a JRST 4, by itself (the job could also send
itself a MJHALT message), then this message will continue the job and return
the old PC word to you. If it was not in STOPQ, then it returns the ECNTC
error with the old queue code in the LH.
The following messages are only from the 6 to the KL. They deal with various
kinds of error conditions that may occur in the running job.
Mnemonic: MAPRER APR error
Type code: 31
Datum: PC word, APR CONI
Reply: none
There are several error conditions the processor itself is set to trap. These
include pushdown-list overflow, memory-protection violation, and non-existant
memory. If your job gets one of these errors, you get this MAPRER message
back, with the status bits from the processor and the PC where the error
occurred. In case you don't know how to decode the CONI word and the PC word,
here are the bit positions: (note: some of these bits are not errors, but
just status, like User mode bit)
APR CONI WORD FOR THE PDP-6
BITS PATTERN NAME INTERPRETATION
--------------------------------------------------------------------------------------
18 400000 CONS flg Yes, Martha, the PDP-6 has a CONS instruction!
19 200000 PDLOV Pushdown-list overflow
20 100000 User IOT mode Makes IO instructions legal in user mode
21 40000 User Mode Enables protection-relocation (on for RTJ)
22 20000 MPV flg Memory protection. Attempted wild reference.
23 10000 NXM flg Non-existant memory. Shouldn't get this.
24 4000 unused
25 2000 CLK enb Enable 60 Hz clock interrupts (will be on)
26 1000 CLK flg Clock interrupt requested
27 400 unused
28 200 PC CHG enb Enable interrupts of PC change
29 100 PC CHG flg Interrupt for PC change requested
30 40 unused
31 20 AROV enb Enable interrupts on arithmetic overflow
32 10 AROV flg Arithmetic overflow interrupt requested
33 APR PIA 4 APRCHN This will be normally set to 7
34 APR PIA 2
35 APR PIA 1
PC WORD FOR THE PDP-6
BITS PATTERN NAME INTERPRETATION
-----------------------------------------------------------------------------------
0 400000,,0 AR OV Arithmetic overflow
1 200000,,0 AR CRY0 Carry 0
2 100000,,0 AR CRY1 Carry 1
3 40000,,0 PC Change Some form of jump was executed
4 20000,,0 BIS Byte increment suppress flag
5 10000,,0 User User mode flag
6 4000,,0 User In-Out IOT user mode enabled
7-17 7777,,0 unused, will be zero
18-35 777777 PC
In each of these errors (except MJHLT), the job is stopped and the queue code
is set to ERRQ. That means to restart the job, you must do an MSTJOB to
put it back in the RUNQ.
Mnemonic: MUUOER Illegal UUO
Type code: 32
Datum: PC word, UUO itself
Reply: none
There are currently only 4 UUOs that are defined for the PDP-6, those are
44, 45, 46, and JRST 4,. Anything else will produce this error message, which
returns you a copy of the PC word (which will point to the location after
the UUO) and the UUO itself (with the effective address calculation done
for you).
Mnemonic: MJHLT Job halted
Type code: 34
Datum: PC word, halt instruction itself
Reply: none
If your job executes a halt instruction, which is a JRST 4,, then you will
receive this message with the PC (which will probably be set to the
effective address of the halt instruction) and the halt instruction itself.
Mnemonic: MADCHK Address check
Type code: 35
Datum: PC word, UUO itself
Reply: none
If the RTJ does a UUO that references an address that is outside of its
core image, it will get this error with the PC word (which will probably
point to one past the UUO) and a copy of the UUO itself.
UUOS FROM THE RTJ
The RTJ communicates with the PDP-6 submonitor via the unused operation
codes (or UUOs) which trap to the monitor. There are currently three
such operations defined.
Mnemonic: SNDMES Send message
Op code: 44
Datum: Effective address points to 0 followed by message
Reply: sequence number deposited in message
This UUO normally skips. This is the way the RTJ communicates both with
its controlling KL job and with the devices on the 6 (such as the DAC, the
KIM, etc etc). For example, to do something with the DAC, the RTJ just
sends a message to device DACDEV. The service routines for the 10/6
interface on the PDP-6 will notice that this message is comming from job
OURJN and will divert it so that it is not sent to the KL but is instead
interpreted as if it were a message from the KL. Thus any message the RTJ
sends out that does not have the F6TO10 bit on in the first word of the
message header will be interpreted locally just as if it came from the KL.
The F6TO10 bit is the thing that determines whether the message is sent to
the KL or interpreted locally.
The effective address of the UUO must point to a block of length at least
2. That is, the word it points to must be a zero, followed by the first
word of the message header, followed by the second word of the message
header, followed by the data part of the message. The reason for this is
that the extra zero word at the beginning is used by the submonitor to
link this message into the output (or input) list. The submonitor will
also deposit the next sequence number into the message itself, and will
also deposit OURJN into the job number position. If the first word is not
zero, the UUO will not skip.
The 6 system will set the zero word to non-zero when the message is
entered into the output queue. It will be zeroed when the message has been
entirely sent to the 10. In fact, if you enter this UUO with a non-zero
link (indicating that this message has already been queued for output),
then the UUO will not skip, and the new message will not be sent.
Mnemonic: RCVMES Receive message
Op code: 45
Datum: Effective address points to 0 followed by message
Reply: none
This UUO skips if there was a message waiting and it transfers the message
to the RTJ core image starting at the effective address of the UUO. Again,
there will be a word in front of the message that should be ignored. It
will not necessarily be zero. If the UUO does not skip, it means there are
no messages waiting for the RTJ. There better be enough space in the RTJ
core image for the message, or else the MADCHK error will be generated.
Mnemonic: GDATA Get data
Op code: 46
Datum: Accumulator contains code
Reply: Requested data stored in AC
This is a multi-function information-getting UUO. You call it by putting
a code in the accumulator referenced by the UUO. Currently the effective
address is ignored, but this might change. Each of the calls is different,
so we will describe them separately below. The UUO skips on success, thus
in the simple information-getting calls, it will always skip.
Mnemonic: JOBOWN Get number of owning job
Op code: 46
Datum: 0 in accumulator
Reply: Returns number of job on KL that owns RTJ
Mnemonic: JOBLEN Get length of RTJ core image
Op code: 46
Datum: 1 in accumulator
Reply: Returns highest legal address in RTJ core image
Mnemonic: JOBADR Get absolute address of origin of RTJ
Op code: 46
Datum: 2 in accumulator
Reply: Returns absolute address in 6 memory of 1st word of RTJ core
Mnemonic: THSDAT Get date
Op code: 46
Datum: 3 in accumulator
Reply: Returns date in system date format
Mnemonic: TIME Get time of day
Op code: 46
Datum: 4 in accumulator
Reply: Returns time of day in 60th of a second from midnight
Mnemonic: CORTAL Get amount of free core
Op code: 46
Datum: 5 in accumulator
Reply: Returns number of 512-word pages still free in 6 memory
Mnemonic: CHKINL Check incomming messages
Op code: 46
Datum: 6 in accumulator
Reply: Returns length of next message, skips if there are any
If there are any incomming messages for the RTJ, this UUO will skip and
return the total length of the first message in the accumulator. If there
are no messages pending, the UUO will not skip.
Mnemonic: EIOTM Enter IOT-USR mode
Op code: 46
Datum: 7 in accumulator
Reply: Puts job in IOT-USR mode
IOT user mode allows the RTJ to do direct PDP-6 IO instructions (CONO, DATAO,
etc) which would normally trap to the monitor and be considered UUOs. The RTJ
must be very careful, because it is quite easy to kill the system this way. For
instance, it could turn off interrupts. There is normally no good reason to
be doing this.
Mnemonic: INWAIT Wait for incomming messages
Op code: 46
Datum: 10 in accumulator
Reply: Waits for messages
If there are no pending messages for the RTJ, this UUO places the job in IOWQ,
wherein it will sit, not running, until a message comes in for it. At which
point it will return from the UUO and continue on as if nothing had happened.
If there are already some messages pending when the UUO is executed, it will
just return immediately. This UUO always takes the skip return.
Mnemonic: UUOTRP Set to trap all illegal UUOs
Op code: 46
Datum: 11 in accumulator, Effective address is trap address
Reply: Sets UUO trap address
Normally all UUOs but the three that are legal for the RTJ are sent back to
the KL for further processing. You can get them to trap to the RTJ itself
by use of this operation. The effective address of the UUO (which has been
unused up to this point) is taken as the first instruction of the UUO trap
routine. When the RTJ next executes a UUO that is not 44, 45, or 46, (or 1-37)
the UUO itself will be put in the effective address location, the PC word
will be placed in that location plus one, and the RTJ will continue at that
location plus two. UUOTRP will be turned off, so that to exit from your
UUO handler, you will have to give another UUOTRP call to reset the trap
status. This is so that UUOs in your UUO handler will get trapped as
errors. Note that UUOs 1 to 37 are automatically trapped by the hardware
into location 40 of the RTJ core image. Location 41 should be a JSR to
your UUO handler.
AN EXAMPLE OF A REAL-TIME JOB
This example is in two parts. One part is a SAIL job that runs on the KL
that initializes the RTJ. The next part is the actual RTJ that is a FAIL
program that should be saved as a dump file.
begin "JOBTST"
define crlf="'15&'12";
integer i,j,k,brk,wc,len,type,dev,seq,errb,dat,jaddr,jlength;
string file,s;
boolean eof,fail;
integer array finfo[1:6],buf['74:'137];
define jobsa="'120";
define mhi="'2000"; Comment - Hi there;
define mtty="'2001"; Comment - TTY message;
require "SIXSAI.DEF[SIX,MUS]" source_file;
open(2,"SIX",'17,0,0,200,brk,eof);
mesini(2);
open(3,"RTJ",0,0,0,200,brk,eof); Comment - Dummy for interlocking;
mesou1(mjini,sysdev);
mesin3(type,dev,errb,seq,dat);
if type≠mjini then
usererr(0,0,"Got back a "&mesnames[type]&" instead of a MJINI");
if dat≠0 then
usererr(0,0,"Didn't initialize properly, datum = "&cvs(dat));
outstr("Type name of dump file: ");
open(1,"DSK",'17,0,0,200,brk,eof);
lookup(1,file←inchwl,fail);
if fail then usererr(0,0,file&" not found!?!!");
fileinfo(finfo);
start_code
move 1,finfo;
movs 2,3(1);
movnm 2,wc;
end;
arryin(1,buf['74],'137-'74+1);
dat←buf[jobsa] lsh -18; Comment Pick up length from core image;
mesou3(mjcore,sysdev,seq,dat);
mesin3(type,dev,errb,seq,dat);
if type≠mjcore then
usererr(0,0,"Got back a "&mesnames[type]&" instead of an MJCORE");
if dat≥0 then
usererr(0,0,"Didn't get core, datum = "&cvs(dat));
jaddr←dat land '777777; Comment this is absolute addr of job;
jlength←-(dat ash -18);
useti(1,1); Comment Get us back to the beginning;
dsk6rd(1,jlength-'74,jaddr+'74);
close(1);
release(1);
mesou3(mstjob,sysdev,seq,buf[jobsa] land '777777);
mesin3(type,dev,errb,seq,dat); Comment Start at entry pt in core image;
if type≠mstjob then
usererr(0,0,"Got back a "&mesnames[type]&" instead of an MSTJOB");
if dat≠0 then
usererr(0,0,"MSTJOB returned a datum?!??, datum = "&cvs(dat));
mesou1(mhi,rtjdev);
mesin1(type,dev,errb);
if type≠mhi ∨ dev≠rtjdev then
usererr(0,0,"Didn't get a HI back, type = "&cvs(type)&", dev = "&cvs(dev));
outstr("Got HI back successfully"&crlf);
while true do
begin "RT"
integer len;
len←meswait;
begin "RW"
integer array data[1:len+2];
mesin(type,dev,errb,seq,len,data);
if type≠mtty ∧ dev≠rtjdev then
usererr(0,0,"Didn't get a MTTY back, type = "&cvs(type)&
", dev = "&cvs(dev))
else begin "PMES"
s←"";
j←point(7,data[1],-1);
while (i←ildb(j))≠0 do s←s&i;
outstr("Message from RTJ: ");
outstr(s);
end "PMES";
end "RW";
end "RT";
outstr("All done!"&crlf);
end "JOBTST"; Comment - Exiting from SAIL will clear the RTJ;
And here is the actual FAIL job . . .
title TSTRTJ
.insert MESDEF[SIX,MUS]
OPDEF SNDMES [044000000000] ; Never skips
OPDEF RCVMES [045000000000] ; Skips if there was a message there
OPDEF GDATA [046000000000] ; Skips upon success, code in AC
; AC codes for GDATA UUO
JOBOWN←0
JOBLEN←1
JOBADR←2
THSDAT←3
TIME←4
CORTAL←5
CHKINL←6
EIOTM←7
INWAIT←10
UUOTRP←11
; Accumulators
ac1←4
p←17
; Private message codes . . .
mhi←←2000 ; Hi there
mtty←←2001 ; TTY message
; Messages . . .
iaa: 0 ; Link word
f6to10!fnowds!mhi,,0 ; Send him a "hi" message
hello: 0 ; Link word
f6to10!mtty,,0 ; Now an actual string message
hlen,,0 ; length to be determined
asciz /Hello from the RTJ!
/
hlen←←.-hello-3 ; Just length of data part
rhelp: 0 ; Link word
f6to10!mtty,,0 ; Now an actual string message
hlen1,,0 ; length to be determined
asciz /RCVMES didn't skip!
/
hlen1←←.-rhelp-3 ; Just length of data part
adone: 0 ; Link word
f6to10!mtty,,0 ; Now an actual string message
hlen2,,0 ; length to be determined
asciz /All done. Success!
/
hlen2←←.-adone-3 ; Just length of data part
badm: 0 ; Link word
f6to10!mtty,,0 ; Now an actual string message
hlen3,,0 ; length to be determined
asciz /Didn't get the message type I expected!?!
/
hlen3←←.-badm-3 ; Just length of data part
inmes: 0 ; Incomming message
block 22 ; Better not be any longer than this
; Program starts here
START: sndmes iaa ; First thing.
wmes: movei ac1,inwait ; Wait for corresponding message
gdata ac1,
jfcl ; Always takes skip return
rcvmes inmes ; Bring in new message
jrst ohelp ; Error if no message
ldb ac1,[point 12,inmes+1,17]
caie ac1,mhi
jrst mhelp
sndmes adone
aoja 0,.
ohelp: sndmes rhelp
wait: movei 0,777777
sojg 0,. ; wait a second so as not to flood
jrst wmes
mhelp: sndmes badm
jrst wait
end START ; This sets the starting address of the RTJ
SYSTEM CALLS FOR THE SIX
There are basically two different things you can do to the six through
the KL: send messages and do disk transfers. Each of these things have their
own formats and UUOs. All this will eventually be described in the UUO manual,
but until it comes, here is how it all works:
DEVICE SIX
There is a device that you can OPEN on the KL (in mode '17 only!) called
SIX. Many different people can have it open at once, but it only makes
sense for each person (job) to have it opened once. You do an OUTPUT
to it to send a message to the 6 and you do an INPUT to receive a message
from the 6. In addition, there is a call (an MTAPE) to find out if there
is a message waiting for you to read it, and an interrupt bit you can
set to receive a user-interrupt each time a new message comes in.
The interrupt bit is called INTSIX and is the 40000 bit (bit 21) in the
right half of the interrupt word. See the chapter on the user interrupt
system in the UUO manual for how to use this bit.
When you CLOSE or RELEASE the device SIX, the system sends out an MCLRJOB
message automatically. This will clear everything the SIX knows about you,
will release any buffers you have claimed, will stop the real-time job if
you have initialized it, etc etc etc.
The exact monitor calls are as follows:
OUTPUT CHN,ADDR
ADDR: IOWD WD,MA
This is the standard system OUTPUT UUO. It takes a single IOWD, not an IO command
list. This IOWD points to a single message. The first word (or the first
two words if it is a multiple-word message) must be in the message
header format described before. The system will deposit the sequence number
it assigns your message into the second word of the message (if any). The
message will be sent out (essentially) immediately. The maximum message
length is 1024 words. Anything longer than this must be broken up into 1K
pieces.
INPUT CHN,ADDR
ADDR: IOWD WD,MA
This is the standard system INPUT UUO. Likewise, it takes a single IOWD, not
an IO command list. This IOWD points to a place where a single message will
be placed by the system. If there are no messages there for you, this UUO
will wait until one comes in (or forever if no messages come in). You will
only get messages that are specifically directed to your job. Generally this
will not happen unless you do something (send a message to the 6) to make
it send you messages. If the IOWD you give is not big enough to hold the
message, you will only get as much of it as will fit.
MTAPE CHN,ADDR
<Failure return> ; Meaning of this return depends on function
<Success return>
ADDR: <Function code>
<Some data may be returned here>
There are only two legal codes right now. Code=0 means "skip if anything
in input list for me". It returns you in ADDR+1 the length (total length,
including header) of the next message in your input queue. It skips if
there is anything in your input list and it does not skip if your input
list is empty (that is, if your next INPUT UUO would have to wait).
Code=1 means wait for something to come into your input list, then return
its length in ADDR+1. It never skips.
DISK TRANSFERS
Disk transfers to the 6 memory operate much the way that normal
disk transfers do, except that they take special monitor calls, and
that the error correction is not done for you. The ECC (error correction
code) bytes are returned to you and you have to send them to the 6 using
the MECC message.
The disk must be open in mode 17 (dump mode). You will get an illegal UUO
from the following MTAPEs if it is not open in mode 17.
MTAPE CHN,ADDR
ADDR: SIXBIT /GODMOD/
24 ; Code for read, 25 for write
IOWD WC,MA ; Memory address relative to 6 memory
ECCADR ; Address (in your core image) where ECC data goes
ECCWD1
ECCWD2 ; ECC status words
BLOCK,,TRACK ; Only relevant on old format UDPs
This is how you read data from the disk into the 6 memory. You give an IOWD,
just like any other disk transfer (only dump mode, mode '17 is legal), only
the memory address you give in this IOWD refers to an absolute location in
the 6 memory, of which there is roughly 64K. The ECC data itself is two
words per entry. There may be up to 19 entries, so that your table of
the ECC data (which starts at location ECCADR) must be at least 38 words long.
Of these two words of data for each error, they are decoded as follows:
WORD 1 BYTE (12) BYTEC (24) BITS
BITS PATTERN NAME INTERPRETATION
---------------------------------------------------------------------------
0:11 777700,,0 BYTEC Byte number within ailing record of bad byte
12:35 77,,777777 BITS 3 ECC bytes to be XORed with the data
WORD 2 -WC,,P3ADDR
The first word gives the byte number within the ailing record of the first
bad byte (8 bits), and the 3 ECC bytes to be XORed in with three data
bytes to make the correction. The next word gives in the right half the
absolute address in P3 memory of the first word of the ailing record.
Thus you take this word and start XORing bytes at BYTEC bytes into this
record. The channel packs nine 8-bit bytes into 2 words in the following
manner.
************************************************************
* * * * * *
* BYTE 0 * BYTE 1 * BYTE 2 * BYTE 3 * BYTE *
* * * * * 4A *
************************************************************
************************************************************
* * * * * *
* BYTE * BYTE 5 * BYTE 6 * BYTE 7 * BYTE 8 *
* 4B * * * * *
************************************************************
BITS PATTERN NAME INTERPRETATION
---------------------------------------------------------------------------
***WORD 1***
0:7 776000,,0 BYTE0 Entire byte 0
8:15 1774,,0 BYTE1 Entire byte 1
16:23 3,,770000 BYTE2 Entire byte 2
24:31 0,,7760 BYTE3 Entire byte 3
32:35 0,,17 BYTE4A High-order 4 bits of byte 4
***WORD 2***
0:3 740000,,0 BYTE4B Low-order 4 bits of byte 4
4:11 37700,,0 BYTE5 Entire byte 5
12:19 77,,600000 BYTE6 Entire byte 6
20:27 0,,177400 BYTE7 Entire byte 7
28:35 0,,377 BYTE8 Entire byte 8
If you decide you have to do the error correction yourself, you have to
decide first which word pair it is in, then figure out what byte within
the word pair it is, and start XORing. Luckily, device SIX will do this
for you if you just send the MECC message.
The first ECC status word returned describes the state of the transfer.
If the left half is not exactly 1, then this word will contain -N,,ADRS,
where ADRS is the first unused location in your error correction data table
and N is the number of unused words at the end of this =38 word table.
This means there were (=38-N)/2 errors and there are =38-N words of ECC
data returned in the table (thus if N is =38, there were no errors).
Unless there were no errors, the ECC data should be sent to the SIX
in an MECC message to have it correct the errors.
If the left half of the first ECC status word is exactly 1, then there
were more than =19 errors over the transfer and some ECC information was
lost. You got corrections for the first =19 errors, and the second ECC
status word will contain the first absolute address in P3 memory of the
first record whose ECC information was lost. The =38 words of ECC
information should be sent to the SIX in an MECC message and the remainder
of the transfer retried. To retry, you will have to know how the
addresses map into blocks and records. For the regular disk and the
new-mode UDPs, it is very simple; there are 200 words to each record. For
old-mode UDPs, it is a little more complicated because you must give the
disk address in terms of the block number and the record number within
that block (see {YONSS UDPSS}). With old-mode UDPs, there are =19 records
per block. The first record is 40 words long and every succeeding record
is 200 words long. Thus the length of each block is =18*200+40.
MTAPE CHN,ADDR
ADDR: SIXBIT /GODMOD/
25 ; Code for write
IOWD WC,MA ; Memory address relative to 6 memory
BLOCK,,TRACK ; Only relevant on old format UDPs
Since there can be no errors on output (according to the disk manual), there
is no need for ECC. Thusly, it is much simpler to write from the 6 memory.
Things should be pretty self-explainatory by this point.
SAIL-CALLABLE ROUTINES
You can save yourself a lot of trouble by using this set of routines which
already exists. These routines live in SIXPAK.FAI[SIX,MUS], thus you can
get them by REQUIRE JAMLIB.REL[SUB,SYS] LIBRARY. The calling sequences
look like this:
External procedure MESINI(integer chan);
External procedure MESOUT(integer type,dev; reference integer seq;
integer len; integer array data);
External procedure MESOU1(integer type,dev);
External procedure MESOU3(integer type,dev; reference integer seq;
integer datum);
External integer procedure MESLEN;
External integer procedure MESWAIT;
External procedure MESIN(reference integer type,dev,errb,seq,len;
reference integer array data);
External procedure MESIN1(reference integer type,dev,errb);
External procedure MESIN3(reference integer type,dev,errb,seq,datum);
External procedure DSK6RD(integer dchan,nwds,p3addr,track(0),blk(0));
External procedure DSK6WR(integer dchan,nwds,p3addr,track(0),blk(0));
Now what these things do is as follows:
External procedure MESINI(integer chan);
This tells the message routines what IO channel you have
opened device SIX on. You must have already OPENed device SIX in
mode '17. No ENTER or LOOKUP is necessary. It is necessary to make
this call before you do any disk input via DSK6RD, because DSK6RD
may have to send ECC data to the 6 for you, thusly it needs the
channel number.
External procedure MESOUT(integer type,dev; reference integer seq;
integer len; integer array data);
External procedure MESOU1(integer type,dev);
External procedure MESOU3(integer type,dev; reference integer seq;
integer datum);
The output routines format the header words for you. They return the
sequence number that the system gives us back. This is for sending
messages to the 6. There is MESOU1, which sends a 1-word message (no datum)
with a given message code (TYPE) and to a specific device service
routine on the 6 (DEV). DEV=0 is the 6 system itself. There is also MESOU3
which sends a 1-word datum (for a total of a 3-word message). For anything
longer than 1 data word, MESOUT should be used. Remember: you can always
send a longer message than you need, up to 1024 words. The 6 will ignore the
extra words you may send. LEN in the MESOUT call is the number of data
words. The total length of the message will be, of course, LEN+2.
External integer procedure MESWAIT;
External integer procedure MESLEN;
External procedure MESIN(reference integer type,dev,errb,seq,len;
reference integer array data);
External procedure MESIN1(reference integer type,dev,errb);
External procedure MESIN3(reference integer type,dev,errb,seq,datum);
MESWAIT just waits for a message to come in if there is not already
one and returns you its length. MESLEN just returns you the length
of the next message in your input queue, or 0 if there isn't any. Once
you get the length, you can call either MESIN, or MESIN1 for 1-word messages
and MESIN3 for 3-word messages. The number that MESLEN returns to you
is the total length of the message, not just the length of the data portion.
The array DATA that you give MESIN, however, is just for the data portion.
The header information is split up and returned in the various formal
parameters given.
ERRB is the error bit. There are two possible errors (not that you can
do much about it if you start getting these errors!).
Errb 1 bit is FNCOMP, meaning that for one reason or another,
this message is not complete. Errb 2 bit is FDMISS, meaning that
some data was clobbered and lost on the way in. This might happen if
the KL drops dead momentarily during a transfer for so long that the 6
times out. Ordinarily, it will not hppen.
In the MESIN case, you enter with LEN being the maximum message
length you are prepared to receive in DATA. Upon return, LEN will
be set to how much data you got. If you didn't get it all, the LH
of ERRB will be set to the actual length of the message. If all
succeeds, ERRB should be zero.
External procedure DSK6RD(integer dchan,nwds,p3addr,track(0),blk(0));
External procedure DSK6WR(integer dchan,nwds,p3addr,track(0),blk(0));
DCHAN is the disk channel. You must have OPENed the disk already on
this channel and given the appropriate combination of LOOKUPs and
ENTERs for what it is you want to do. NWDS is the number of data
words in the transfer. P3ADDR is the absolute address of the first
word of the transfer in the 6 memory. For old format UDPs, you should
also include the track and block number within that track. For regular
file disk and new-format UDPs, these parameters are irrelephant and may
be defaulted to zero. Again, don't forget that you must open the disk
in dump mode, mode 17 (octal).
A SAIL PROGRAM TO READ THE PANELS
This program doesn't really do much, but it is debugged and it works. It
listens to the KIM panel interface and types out every change the KIM
software sends it.
begin "KIMRD"
integer i,j,k,type,dev,len,errb,seq,panel,group,key,bytno,timorg,midnite;
integer array state[0:255],data[1:2];
integer brk;
boolean eof;
define crlf="'15&'12";
define α=" comment ";
require "JAMLIB.REL[SUB,SYS]" library;
External procedure MESINI(integer chan);
External procedure MESOU1(integer type,dev);
External procedure MESIN(reference integer type,dev,errb,seq,len;
reference integer array data);
define kimdev="5";
define mnewd="'1010"; Comment - New datum, 6→KL;
define msend="'1011"; Comment - Start sending;
define mstop="'1012"; Comment - Stop sending;
define mstate="'1013"; Comment - Send entire state;
midnite←24*60*60*60;
timorg←-1;
open(1,"SIX",'17,0,0,200,brk,eof);
open(2,"KIM",0,0,0,200,brk,eof); α Dummy to keep other people out;
mesini(1);
mesou1(mstate,kimdev);
do begin "RM"
len←256;
mesin(type,dev,errb,seq,len,state)
end "RM" until type=mstate ∧ dev=kimdev;
mesou1(msend,kimdev);
while true do
begin "LIST"
len←2;
mesin(type,dev,errb,seq,len,data); α Ignore everything but KIM messages;
if type=mnewd ∧ dev=kimdev then
begin "ND"
if timorg<0 then timorg←data[2]; α Count time from first stroke;
bytno←ldb(point(7,data[1],19));
panel←bytno lsh (-3);
group←bytno land '7;
i←data[2]-timorg;
if i<0 then i←i+midnite; α Correct for wraparound;
outstr("Time = "&cvf(i/60.0)&", P="&cvs(panel)&" K=");
if (data[1] land '000040000000)≠0 then outstr("**DM** ");
for key←0 step 1 until 7 do
if ((1 lsh key) land data[1])≠((1 lsh key) land state[bytno]) then
begin "NK"
outstr(cvos((group lsh 3)+key));
if ((1 lsh key) land data[1])≠0 then outstr("↓ ")
else outstr("↑ ");
end "NK";
state[bytno]←data[1]; α Update state of panels;
state[bytno+128]←data[2];
outstr(crlf);
end "ND";
end "LIST";
end;
RESTARTING AND RELOADING THE PDP-6
The 6 itself is subject to a number of ailments, most of which will
probably be recurring. The most common symptom of which is that it
ceases to respond at all. The right thing to do in that case is
to reload the 6 submonitor. There are two ways to do that, depending
on how badly the 6 is clobbered. The simplest thing to try is to
say "R SIXFIX". When it exits, it has attempted to reload the 6. If
the 6 is still not responding, then you must intervene manually.
You go over to the 6 and press the "STOP" key. Then you depress
the "IO RESET" key. Then you go to a terminal and type
"RU DSKLOD[SIX,MUS]". When it asks you for a file name, you type
"SIXSYS.DMP[SIX,MUS]". When it exits, you go over to the 6, set the
address switches to 200 (octal. 10000000 in binary) and press "START".
The teletype will chatter for a while and the six should go into its
idle loop, which blinks the lights once a second (its "heartbeat"). If
it fails to do so, something is bad wrong.
THE KIM DATA COLLECTION SYSTEM
There are some number of devices located in and around the music
lab. These include several organ keyboards, boxes with knobs on and around them,
and computer terminals. All these things are inputs to the computer and all go through
a single microcomputer, called the KIM (Keyboard Interface Monitor), which
services all these devices and forwards the data to the KL10 (the timesharing
system itself). The point of doing this is manyfold: one is that it reduces the
number of wires between the music lab and the KL10, another is that the KIM
replaces a fair amount of circuitry that would be required to scan the
real-time input devices (organ keyboards and pot boxes).
Before we get into it, let us define some terminology:
KEYBOARD - These refer to terminals for the KL10 computer.
KLAVIER - Engaging in a slight abuse of terminology here, we will
use this word to refer to an organ keyboard.
POT BOX - This refers to a bank of up to 8 potentiometers, either linear
(slide-pots) or rotational.
PANEL - Either a klavier or a pot box. Other devices might come up in the future
that could be considered panels also.
The KIM system has basically three devices on it: the keyboard interface, the
panel interface, and the serializer.
The keyboard interface allows up to 8 Stanford keyboards to be connected to
the KIM. This provides both a system for scanning the keyboard (what is
called "spacewar" mode in the UUO manual), and for receiving interrupts
from the keyboard when a key is first depressed.
Figure ***B shows the physical layout of the front and back of the KIM bay.
These include the KIM rack, the KIM interface rack,
the panel connector rack, and the keyboard
connector rack on the front. On the back we find the 5V power supply and the
15 volt (plus and minus) power supply.
Note: the keyboard input goes through the KIM, but the 6 itself is not
necessary for the characters to get from your keyboard to the KL. They
are forwarded automatically by the interface without ever disturbing
the 6. You can even stop the 6 dead and the keyboards will continue
to work.
KIM CABLES
The KIM itself has two 44-pin connectors on it. These are called
the "application" connector and the "expansion" connector. We bring
all the wires (except power) down to the DEC rack below on four
26-conductor flat cables each (for a total of 8 flat cables). These
alternate signal and ground for crosstalk suppression. These cables
carry all kinds of stuff, including the 8-bit bidirectional data bus
from the 6502 processor, the 16-bit address lines, the interrupt control,
clock signals, reset signal, and many others. In the table below, the
column marked "pin" refers to the pin name on the KIM connectors. These
are numbered A or E (for application and expansion) followed by a hyphen,
followed by the number 1 to 22, or the letter A through Z (with some
missing). This is how the pins on the KIM connectors are numbered. The
column marked DEC are where the corresponding signals are located on
the DEC rack below. Again, it is slot-paddle-pin. Direction is "→" for
KIM to DEC rack, "←" for DEC rack to KIM, and "↔" for bidirectional.
When two different arrows are shown, the first one is the possible
usage, the second one is the current usage. For example, the PAx and PBx
bidirectional ports are commonly used in only one direction at a time.
Thus they are marked with a "↔" to show that they can transmit and receive,
but followed by either "→" or "←" to indicate the current usage.
Application connector pins A-1 through A-13 are found on 1BC1 through
1BS1, pins A-14 through A-22 are on 1BD2 through 1BT2. Pins A-A through
A-P are on 1AC1 through 1AS1. Pins A-R through A-Z are on 1AD2 through
1AT2.
Expansion connector pins E-1 through E-13 are found on 2BC1 through
2BS1, pins E-14 through E-22 are on 2BD2 through 2BT2. Pins E-A through
E-P are on 2AC1 through 2AS1. Pins E-R through E-Z are on 2AD2 through
2AT2.
PIN DEC DIRECT. NAME COMMENT
-----------------------------------------------------------------------
A-1 1BS1 GND
A-2 1BR1 ↔ PA3
A-3 1BP1 ↔ PA2
A-4 1BN1 ↔ PA1
A-5 1BM1 ↔ PA4
A-6 1BL1 ↔ PA5
A-7 1BK1 ↔ PA6
A-8 1BJ1 ↔ PA7
A-9 1BH1 ↔ → PB0 Used for PID for panels
A-10 1BF1 ↔ ← PB1 ¬KL10 busy (needs 75 ohms to gnd!)
A-11 1BE1 ↔ ← PB2 ¬PDP-6 busy (needs 75 ohms to gnd!)
A-12 1BD1 ↔ PB3
A-13 1BC1 ↔ PB4
A-14 1BT2 ↔ PA0
A-15 1BS2 ↔ PB7
A-16 1BR2 ↔ PB5
A-17 1BP2 ↔ KB Row 0
A-18 1BN2 ↔ KB Col F
A-19 1BM2 ↔ KB Col B
A-20 1BL2 ↔ KB Col E
A-21 1BK2 ↔ KB Col A (also white, short to A-V for TTY)
A-22 1BJ2 ↔ KB Col D
A-A 1AS1 +5V
A-B 1AR1 ↔ → ¬K0
A-C 1AP1 ↔ → ¬K1
A-D 1AN1 ↔ → ¬K2
A-E 1AM1 ↔ → ¬K3
A-F 1AL1 ↔ → ¬K4
A-H 1AK1 ↔ → ¬K5
A-J 1AJ1 ↔ ← ¬K7
A-K 1AH1 ← ¬DECODE ENABLE
A-L 1AF1 ← AUDIO IN (also foil cable 107)
A-M 1AE1 → AUDIO OUT LOW (also foil cable 106)
A-N 1AD1 +15V
A-P 1AC1 → AUDIO OUT HIGH (also foil cable 105)
A-R 1AT2 TTY KBD RETURN(+) (also white wire)
A-S 1AS2 TTY PTR RETURN(+) (also white wire)
A-T 1AR2 ← TTY KBD (also blue/yellow wire)
A-U 1AP2 → TTY PTR (also brown wire)
A-V 1AN2 ↔ KB Row 3 (also white/orange, short to A-21 for TTY)
A-W 1AM2 ↔ KB Col G
A-X 1AL2 ↔ KB Row 2
A-Y 1AK2 ↔ KB Col C
A-Z 1AJ2 ↔ KB Row 1
E-1 2BS1 → SYNC
E-2 2BR1 ← RDY
E-3 2BP1 → CLOCK 1
E-4 2BN1 ↔ ← ¬IRQ Interrupt request line
E-5 2BM1 ← RO
E-6 2BL1 ↔ → ¬NMI Non-maskable interrupt request
E-7 2BK1 ↔ → ¬RST Reset. Master clear.
E-8 2BJ1 ↔ DB7 This is the KIM's data bus
E-9 2BH1 ↔ DB6 "
E-10 2BF1 ↔ DB5 "
E-11 2BE1 ↔ DB4 "
E-12 2BD1 ↔ DB3 "
E-13 2BC1 ↔ DB2 "
E-14 2BT2 ↔ DB1 "
E-15 2BS2 ↔ DB0 "
E-16 2BR2 ↔ → ¬K6
E-17 2BP2 → SST OUT
E-18 2BN2 N.C.
E-19 2BM2 N.C.
E-20 2BL2 N.C.
E-21 2BK2 +5V
E-22 2BJ2 GND
E-A 2AS1 → AB0 Address bus (low order here)
E-B 2AR1 → AB1 "
E-C 2AP1 → AB2 "
E-D 2AN1 → AB3 "
E-E 2AM1 → AB4 "
E-F 2AL1 → AB5 "
E-H 2AK1 → AB6 "
E-J 2AJ1 → AB7 "
E-K 2AH1 → AB8 "
E-L 2AF1 → AB9 "
E-M 2AE1 → AB10 "
E-N 2AD1 → AB11 "
E-P 2AC1 → AB12 "
E-R 2AT2 → AB13 "
E-S 2AS2 → AB14 "
E-T 2AR2 → AB15 Address bus (high order here)
E-U 2AP2 → CLOCK 2
E-V 2AN2 → R/W High is read, low is write
E-W 2AM2 → ¬R/W
E-X 2AL2 → PLL TEST
E-Y 2AK2 → ¬CLOCK 2
E-Z 2AJ2 → RAM/R/W
All outputs are TTL compatible, but they are low-current outputs, so that
you have to listen to them either with a low-power Shotky gate, or with
a bus listener (like the 8Txx series: 8T26, 8T95, etc).
There is an EIA converter connected between the KIM and the EIA connector
on the front of the KIM panel. It is quite straightforward, using standard
EIA conversion chips. On the EIA connector, pins 1 and 7 are ground, pin 2
is KIM transmit (to the KL10), and pin 3 is KIM receive (from the KL10).
Note that the KIM does echoing on the TTY line by having the receive
line directly ORed with the transmit line. Thus even with the KIM stopped,
the device will echo, so echoing doesn't necessarily mean anything
intelligent is happening, but it is a handy way to test the TTY link.
LOADING THE KIM PROGRAM
First, you should try to revive the KIM the easy way. Go to the KIM,
press reset (RS). The lights should light up. If not, check the TTY/KBD
switch on front to make sure it is on KBD. If lights still don't light up,
something bad is wrong. Check fuses, power, etc etc. If lights light up,
press address (AD) followed by 0200 (must type all four digits). The right
two lights should read A9. If they don't, you must reload the KIM program
by the involved process described below. If they do, then hit GO. The lights
should go out. To check things, you can type stop (ST) at any time. The
lights should come on. To continue, just press GO again.
If the above simple procedure doesn't work, then you must get to a
terminal (or get a friend to go to a terminal), log in, and type DIAL
TTY16. There is one terminal in 267 that doesn't go through the KIM. That
is TTY36. You can use it (if it is working) to reload the KIM. When it
says "READY", you are then connected to the line that goes to the KIM.
Next plug the EIA connector from the KL10 into the KIM (this should
normally be unplugged or it will screw up the system). Next flip the
TTY/KBD switch on the front panel to TTY. Hit reset (RS) on the KIM
touch-keyboard. Walk over to your terminal and type the single character
backspace (BS). The KIM should respond with "KIM" followed by 6 or so
assorted hex characters and some spaces. Then type the single letter L
(upper case only!!!). The KIM is now in its loader loop. Type <META>I to
DIAL. It will respond "Input file name:". Type PROG.LOD[KIM,MUS] followed
by return. You will see lines of stuff that should start with a colon and
be a bunch of hex afterwards. This will spew on for a few screenfuls,
after which the KIM will type out "KIM" and 6 or so hex digits like it did
in the beginning. Your program is then loaded into the KIM. Walk over to
the KIM now, unplug the EIA connector, turn the TTY/KBD switch to KBD, and
press reset (RS) on the KIMs touch-keyboard. The lights should light up.
Type address (AD) followed by the hex address 0200. You should see these
digits appear on the four numerals on the left. I think what you will see
on the right is A9, the code for the first instruction of the KIM's
program. Press GO. The lights will go out. The KIM is then officially on
the air. (Make sure the SST switch is OFF!). If you want to make sure the
thing is running, press stop (ST). The lights should light up again. The
address will probably be 236 or something like that. If they don't light
up, something is broken. You ought to try to reload the program again,
because sometimes it gets garbled coming through the line. Press GO
(without any intervening keys) to continue the program. The KIM's program
can be restarted at 0200 at any time without hurting anything. If it
doesn't work, you might try the whole loop again, because sometimes we get
scrambled characters over the TTY16 line. If after three times it really
doesn't work, forget it, it is probably dead.
REMEMBER: You MUST unplug the EIA connector from the KIM!
WARNING: TTY36 has really 2 different ways of access. There is the Tovar
serializer and the KIM. Now to reload the KIM, you need access to a
terminal that does not go through the KIM, and TTY36 via the TVR
serializer seems like a likely choice, since it is right there. The only
problem is that since the TVR serializer is a bit noisy (it sometimes
generates stray characters spontaneously), it is preferable to have that
keyboard plugged instead into the TTY36 slot in the KIM. This means that
if the KIM drops dead, to reload it you will have to unplug it from the
KIM and plug it rather into the TVR serializer box. Hopefully these things
are around somewhere.
PANEL CONNECTORS
The panel connectors are Cinch type "D" 25-pin connectors (in fact, ours
are made by Amphenol). This is the
connection list. The pins are simply numbered 1 to 25. These numbers
are marked on the connectors themselves. In the drawings for the
Klavier and pot box interfaces, DEC-style connector pin labels are used.
This is just an artifact of the drawing program, but for your convenience,
the correspondance is listed below:
PIN LABEL NAME COMMENT
-----------------------------------------------------------------------
1 AD1 ¬BDATA 04 Bidirectional 8-bit data bus
2 AE1 GND
3 AF1 PADDR0 Low order 3-bits of device address
4 AH1 PADDR1 "
5 AJ1 PADDR2 "
6 AK1 GND
7 AL1 ¬BDATA 00 Bidirectional 8-bit data bus
8 AM1 +5V TTL supply
9 AN1 ¬BDATA 01 Bidirectional 8-bit data bus
10 AP1 GND
11 AS1 ¬BDATA 02 Bidirectional 8-bit data bus
12 AU1 GND
13 AV1 ¬BDATA 03 Bidirectional 8-bit data bus
14 AD2 ¬SELECT Panel select
15 AE2 +5V TTL supply
16 AF2 ¬BDATA 05 Bidirectional 8-bit data bus
17 AH2 +15V Analog supply
18 AJ2 ¬BDATA 06 Bidirectional 8-bit data bus
19 AK2 -15V Analog supply
20 AL2 ¬BDATA 07 Bidirectional 8-bit data bus
21 AM2 GND
22 AN2 PCLK Clock 2 from the KIM (1 microsecond)
23 AP2 PREAD True for reading from panel
24 AS2 ¬PCLEAR Master clear from KIM
25 AU2 ¬PID Asks panel for identification byte
For panel designers, the addresses (PADDR0, PADDR1, PADDR2, and SELECT),
the read/write flag (PREAD), and the identification flag (PID) all become
valid sometime before PCLK rises. PCLK is about 350 ns long and data
is strobbed about 250 ns into it. For reading, you should put your data
on the line as soon as the addresses and select become valid to allow
lots of settling time. It is guaranteed that the bus is not busy when these
signals become valid. For writing, you should strobe the data on the
fall of PCLK, although it will be valid at the rise of PCLK.
The data from these connectors goes through two pairs of flat cables
to slots A17 and B17 on the KIM backplane. There are two EIA connectors
on the back of the panel sockets labeled A17 and B17. The Wiring of those
connectors is as follows: The label is the label on the KIM backplane.
PIN LABEL NAME COMMENT
-----------------------------------------------------------------------
1 A17C1 ¬BDATA 04 Bidirectional 8-bit data bus
2 A17D1 PADDR0 Low order 3-bits of device address
3 A17E1 PADDR1 "
4 A17F1 PADDR2 "
5 A17H1 ¬BDATA 00 Bidirectional 8-bit data bus
6 A17J1 ¬BDATA 01 Bidirectional 8-bit data bus
7 A17K1 ¬BDATA 02 Bidirectional 8-bit data bus
8 A17L1 ¬BDATA 03 Bidirectional 8-bit data bus
9 A17M1 ¬BDATA 05 Bidirectional 8-bit data bus
10 A17N1 ¬BDATA 06 Bidirectional 8-bit data bus
11 A17P1 ¬BDATA 07 Bidirectional 8-bit data bus
12 A17R1 GND
13 A17S1 PCLK Clock 2 from the KIM (1 microsecond)
14 A17D2 ¬PCLEAR Master clear from KIM
15 A17E2 ¬PID Asks panel for identification byte
16 A17F2 PREAD True for reading from panel
17 A17H2 N.C.
18 A17J2 N.C.
19 A17K2 N.C.
20 A17L2 N.C.
21 A17M2 N.C.
22 A17N2 N.C.
23 A17P2 GND
24 A17R2 GND
25 A17S2 GND
1 B17C1 ¬PANEL SEL 00 Select for panel 0
2 B17D1 ¬PANEL SEL 01 " 1
3 B17E1 ¬PANEL SEL 02 " 2
4 B17F1 ¬PANEL SEL 03
5 B17H1 ¬PANEL SEL 04
6 B17J1 ¬PANEL SEL 05
7 B17K1 ¬PANEL SEL 06
8 B17L1 ¬PANEL SEL 07
9 B17M1 ¬PANEL SEL 10
10 B17N1 ¬PANEL SEL 11
11 B17P1 ¬PANEL SEL 12
12 B17R1 ¬PANEL SEL 13
13 B17S1 ¬PANEL SEL 14
14 B17D2 ¬PANEL SEL 15
15 B17E2 ¬PANEL SEL 16
16 B17F2 ¬PANEL SEL 17
17 B17H2 N.C.
18 B17J2 N.C.
19 B17K2 N.C.
20 B17L2 N.C.
21 B17M2 N.C.
22 B17N2 N.C.
23 B17P2 GND
24 B17R2 GND
25 B17S2 GND
THE POT BOXES
The pot boxes are a type of panel. Specifically, they are type 2 to the
KIM system, and are (internally in the KIM program) treated differently
from Klaviers. The pot box consists of two parts: the pots and the
electronics. The electronics has two EIA connectors on it: one to go back
to the panel sockets on the KIM and one to go the pots themselves. This is
the wiring of the connector that goes to the pots themselves. Any 0 to
+10V signal may be introduced in the place of the pots, so any analog
input can be accepted there. These AD converters are not terribly fast,
and no sample-hold unit is used, so they cannot change very fast. In fact,
the amplifier in the electronics is deliberately limited in frequency
response to 5Kc, because this matches the speed of the AD converter.
PIN NAME CABLE COMMENT
-----------------------------------------------------------------------
1 POT1 16 Clockwise rotation DECREASES the potential.
2 GND 15 because there is an inversion in the logic
3 POT2 14
4 GND 13
5 POT3 12
6 GND 11
7 N.C. N.C. means "not connected"
8 N.C.
9 POT4 10
10 GND 9
11 POT5 8
12 GND 7
13 N.C.
14 N.C.
15 N.C.
16 REF X Extra wire. +10V reference potential.
17 N.C.
18 N.C.
19 N.C.
20 POT6 6
21 GND 5
22 POT7 4
23 GND 3
24 POT8 2
25 GND 1 (cable wire 1 has the red stripe)
Since these plugs look a lot like the panel connectors, these pins were
deliberately chosen so that total disaster will not occur if a pot row
were to be plugged into a panel plug, although it will certainly stop
the KIM, and may even fry some dips.
The electronics has an 8-word by 8-bit buffer on board. It is set to run
the ADC as fast as it can, constantly doing conversions and storing the
results in this little memory. Any time the KIM wants a word, then, it
gets the last word that was placed in this memory. The pot box takes 512
microseconds for each conversion, so the total rate is 4.096 milliseconds
to reference all the pots. This also corresponds to roughly the maximum
time it would take the KIM to scan all the panels, so it is a reasonable
compromise with reality. This way, the KIM can reference the pot box any
time it wants to without having to wait for a conversion.
BURNDY CONNECTORS
Stanford keyboards are connected to the world by 32-conductor
Burndy connectors. The keyboards put out (currently) six character
bits, four shift bits (CTRL, META, TOP, SHIFT), and one timing
(strobe) bit. There are provisions for two more data bits that are
not used at the present time. +5V power and ground is also transmitted
through this cable. Figure ***B shows a drawing of the layout and connection
of the Burndy connector and the cables we commonly use at Stanford.
For the KIM interface, 16-conductor flat cable is soldered to the pins
of the Burndy connector, and the other end is grunched to a 3M dip-socket
plug. This way, a terminal just plugs into a circuit board just like
another dip. There are thusly 3 different numbers that these signals
have. There is the Burndy connector name, which is a single letter
(upper case and lower case are different!). There is the pin number
on the dip socket connector, and there is the wire number in the flat
cable (number 1 is the red stripe).
PIN BURNDY CABLE NAME COMMENT
-----------------------------------------------------------------------
1 b 2 STROBE Note that this is in hi-true form
2 R 4 ¬0 One of the unused bits
3 N 6 ¬META Turned off when Meta depressed
4 L 8 ¬TOP
5 J 10 B4 One of the 6 data bits
6 G 12 B6 "
7 E 14 B2 "
8 c, g 16 GND Grounded at both ends
9 D 15 B1 One of the 6 data bits
10 F 13 B3 "
11 H 11 B5 "
12 K 9 ¬SHIFT
13 M 7 ¬CONTROL
14 P 5 ¬1 One of the unused bits
15 c, g 3 GND
16 c, g 1 GND
THE KIM TTY INTERFACE
The KIM has the possibility of interfacing 8 Stanford keyboards to
the system. These keyboards put out a (potentially) 13-bit datum which
is transmitted to the KL10 via a bit-serial line. Since the KIM works
with 8-bit bytes, then each keyboard has to occupy two bytes. These are
arranged so that the low order bytes are on even memory addresses and
the high order bytes are on odd memory addresses. In addition, there
is an interrupt scheme, whereby when a key is hit on any of the keyboards,
the KIM receives an interrupt. Figure ***Ca through ***Cr show the
drawings for the KIM. The keyboard interface is specifically drawings
***Ci through ***Cr. ***Ci and ***Cj form the control and interrupt
card. ***Ck through ***Cn are the receivers and bus drivers for keyboards
0 through 3, and drawings ***Co through ***Cr are the receivers and
bus drivers for keyboards 4 through 7. Currently this last card does not
exist and is not plugged in (keyboards 4 through 7), although the backpanel
wiring exists for this card should it ever be needed. Because the card
is not plugged in, the strobe lines must be grounded to prevent spurious
interrupts from happening. This is done with some simple daisy-chain wire
on the backpanel. If this should ever get pulled out, you can replace it
by just grounding 7AB2, 7AE2, 7BB2, and 7BD2. (That means slot 7, A
or B paddle, A is upper, B is lower, pin B2, E2, etc).
The base address for the teletype words is E400 (in hex). Keyboard 0
takes E400 and E401, keyboard 1 takes E402 and E403, etc. The interrupt
word is E410. The bits come in as follows:
EVEN LOCATIONS: (E400, E402, E404, E406, E408, E40A, E40C, and E40E)
Bit 0 B1
Bit 1 B2
Bit 2 B3
Bit 3 B4
Bit 4 B5
Bit 5 B6
Bit 6 ¬SHIFT
Bit 7 ¬TOP
ODD LOCATIONS: (E401, E403, E405, E407, E409, E40B, E40D, and E40F)
Bit 0 ¬CONTROL
Bit 1 ¬META
Bit 2 ¬1
Bit 3 ¬0
Bit 4 STROBE
Bit 5 (unused)
Bit 6 (usused) These bits will be 0 (off).
Bit 7 (unused)
INTERRUPT LOCATION: (E410)
Bit 0 ¬KBD 00 IRQ These will be 1 (on) normally.
Bit 1 ¬KBD 01 IRQ They are lowered when a key is typed.
Bit 2 ¬KBD 02 IRQ
Bit 3 ¬KBD 03 IRQ
Bit 4 ¬KBD 04 IRQ
Bit 5 ¬KBD 05 IRQ
Bit 6 ¬KBD 06 IRQ
Bit 7 ¬KBD 07 IRQ
The corresponding bit in E410 is lowered (set to 0) when a key is typed
on a keyboard. It remains low, and an interrupt is requested until either
the even or odd data word of that keyboard is read. When one or the other
of the data words for that keyboard is read by the KIM, then the interrupt
request for that keyboard is cleared and the corresponding bit in
E410 is again raised.
P.S. - Actually, bit 9 of the address is not decoded on these operations,
so each of these may be referenced both at E4xx but also at E6xx.
THE KIM PANEL INTERFACE
The panel interface is pretty straightforward. The panel consists of
128 bytes of data, arranged into 16 groups of eight bytes each. Each
panel supplies one of 8 different bytes on command. Thusly, a 3-bit
address and a low-true select line are delivered to each panel. The
select says that the high order bits match up so that one of the
8 bytes from this panel is desired. The 3-bit address is just the low-order
3 bits from the KIM. The addresses are from E000 (hex) to E07F by eights.
Thus panel 0 goes from E000 to E0007, panel 1 goes from E008 to E00F, and
so on. Although the panels may be bidirectional, there is no provision for
anything but output devices now.
Each panel not only can supply one of eight data bytes, but it can also
supply an identification byte. This is done when the processor asserts
PB3 (peripheral bus B, bit 3), then reads from a panel the highest byte
of its eight byte (E007 for panel 0, E00F for panel 1). This byte is
then an identification byte. It has two parts. There is a 3-bit panel
type number and a 5-bit identification number within that panel type.
Three of the possible four panel type numbers are in use. Type 0 means
nothing is plugged into this panel. Type 1 means pushbuttons (like the
Klavier) and switches, and type 2 are the analog pot boxes.
Other types are not assigned and are ignored by the KIM.
For panel builders, each panel should have a unique 5-bit ID number so
the program can uniquely identify what panels are plugged in where without
prompting. Also, signals like the select line will have occaisional glitches
and spikes on them, so they shouldn't be used for clocking things. Only
the clock signal (PCLK) is advertised to have clean edges, and that is somewhat
suspect due to the unterminated nature of these lines. It is thus recommended
that things be received with hysteresis receivers (like the 74LS14).
Also, the data bus should be driven with high-current drivers like
8T96 or something, because they are terminated with 220/330 dividers with
an effective resistance of 150 ohms to about +3 volts. Since the data bus
is low-true, that means that not driving a given line will produce a logical
zero on that line.
THE KIM SERIALIZER INTERFACE
The KIM has a 32-bit serial interface for communicating with the PDP-6
and the KL-10. The interface works on a pulse-width modulation scheme, where
all bits are 200 ns long, with a zero represented by a 67 ns high period followed
by 133 ns of low, and a one represented by a 133 ns high period followed by 67
ns of low. When idle, the serializer transmits zeros continuously.
The serializer is reset by depositing into its first byte (address EBFC). It
fires off the 32-bit datum when the last byte is deposited (address EBFF).
The high byte (EBFF) contains a header which identifies what processor, PDP-6
or KL10, the datum is bound for. A header of 11110011 (F3 in hex) will
send that datum to the KL10, and a header of 11110101 (F5 in hex) will send that
datum to the PDP-6. These are independent paths, and 8 microseconds after
the header word is deposited by the KIM, another word to the other receiving
processor can be sent out. There are also return lines from the processors
which say whether the buffer on the 6 or the 10 is busy or not. These are
low-true busy signals. They are brought in on the peripheral bus B, bits
1 and 2. PB1 low means PDP-6 buffer is busy and cannot accept another datum.
PB2 low means the KL10 buffer is busy and cannot accept another datum.
Since 8 bits are used for the header, the datum is only really 24 bits
long. That is, only 24 bits are actually received by the PDP-6 or the
KL10.
THE KIM BACKPLANE
The DEC rack that houses all the various KIM interfaces was designed (to some
extent) for some amount of expandibility. To this end, the major bus, address,
and control signals are strapped across the backplane up to and including slot
16. Since only slots 1 through 7 are used (and slot 17), there are slots
8 through 16 available for new devices on the KIM. Since address bits 0 through
8 (the low-order 9 bits) are bussed across the back, 4 extra low-true selects
are generated that are available. These are outputs of 74LS145 with 1K pullups
and thus should not be loaded too heavily. These are located as follows:
¬AUX 01 SEL 4AD1
¬AUX 02 SEL 4AB1
¬AUX 03 SEL 4AA1
¬AUX 04 SEL 4AB2
The signals that are bussed across the backplane are as follows:
NAME LOC DIRECT. COMMENT
-----------------------------------------------------------------------
¬BDATA 00 AV2 ↔ Bidirectional 8-bit data bus
¬BDATA 01 AU2 ↔ Is terminated with 220/330 resistors
¬BDATA 02 AS2 ↔ Must be driven with 8Txx series
¬BDATA 03 AR2 ↔
¬BDATA 04 AP2 ↔
¬BDATA 05 AN2 ↔
¬BDATA 06 AM2 ↔
¬BDATA 06 AL2 ↔
BADDR 00 BV1 →
BADDR 01 BU1 →
BADDR 02 BS1 →
BADDR 03 BR1 →
BADDR 04 BP1 →
BADDR 05 BN1 →
BADDR 06 BM1 →
BADDR 07 BL1 →
BADDR 08 BK1 →
MRCLEAR BJ1 → Master reset
¬MRCLEAR BJ2 →
READ BH1 → High for data to KIM, low for from KIM
¬READ BH2 →
MRCLK BF1 → CLOCK 2, 1 microsecond
¬MRCLK BF2 →
HI BE1 → +3V reference, 8T96 driving
¬INT REQ BE2 ← Interrupt request (with pullup)
THE DATA LINES
There are roughly 16 cables running from the music room to 267 (the music
lab). These cables are RG59-U single conductor shielded 75 ohm coaxial
cable and are used for digital signals only. They are numbered (hopefully!)
at each end
OTHER HARDWARE
Other hardware is mostly on the 6 itself. This includes the TTL IO BUS,
the TTL IO BUS EXTENSION (which includes several devices), and the DAC.
All the drawings for these things are in Aco-press binders up on top of the
KA-10, where all the other system drawings are, but in addition, they may
be found on these areas:
TTL IO BUS [TTI,MUS]
TTL IO BUS EXTENSION [IOB,MUS]
10/6 INTERFACE [INT,MUS]
(This is the identical same thing as the FRM interface. One
size fits all)
PARALYZER [PAR,MUS]
DAC [DAC,MUS]
ADC [ADC,MUS]
UML - TTL IO BUS
The following is the card layout for the TTL devices on the 6 at
the time of this writing:
TTL IO BUS
*************************************************************************************************
*A1|A2|A3|A4*A5|A6|A7|A8*A9|10|11|12*13|14|15|16*17|18|19|20*21|22|23|24*25|26|27|28*29|30|31|32*
* | | | * | | | * | | | * | | | * | | | * | | | * | | | * | | | *
* T| T| | * | | | * | | | * | T| T| T* | | 6| 5* 6| 5| 6| 5* I| I| I| I* I| I| I| I*
* T| T| | * | | | * | | | * | I| I| I* | | 6| 6* 6| 6| 6| 6* O| O| O| O* O| O| O| O*
* L| L| | * | | | * | | | * | O| O| O* | | 4| 4* 4| 4| 4| 4* B| B| B| B* B| B| B| B*
* | | | * | | | * | | | * | B| B| B* | | | * | | | * | | | * | | | *
* C| C| | * | | | * | | | * | 1| | * | |LC|LC*LC|LC|LC|LC* 1| 2| 3| 4* 1| 2| 3| 4*
* B| B| | * | | | * | | | * | |N=|N=* | | | * | | | * A| A| A| A* A| A| | *
* L| L| | * | | | * | | | * | |18|00* | |N=|N=*N=|N=|N=|N=* | | | * | | | *
* | | | * | | | * | | | * | | | * | |00|00*16|16|32|32*N=|N=| | *N=|N=| | *
* 1| 3| | * | | | * | | | * | | | * | | | * | | | *00|18| | *00|18| | *
* | | | * | | | * | | | * | | | * | | | * | | | * | | | * | | | *
*************************************************************************************************
*B1|B2|B3|B4*B5|B6|B7|B8*B9|10|11|12*13|14|15|16*17|18|19|20*21|22|23|24*25|26|27|28*29|30|31|32*
* | | | * | | | * | | | * | | | * | | | * | | | * | | | * | | | *
* T| | | * | | | * | | | * | T| T| T* | 5| 6| 5* 6| 5| 6| 5* I| I| I| I* I| I| I| I*
* T| | | * | | | * | | | * | I| I| I* | 6| 6| 6* 6| 6| 6| 6* O| O| O| O* O| O| O| O*
* L| | | * | | | * | | | * | O| O| O* | 4| 4| 4* 4| 4| 4| 4* B| B| B| B* B| B| B| B*
* | | | * | | | * | | | * | B| B| B* | | | * | | | * | | | * | | | *
* C| | | * | | | * | | | * | 1| | * |LC|LC|LC*LC|LC|LC|LC* 1| 2| 3| 4* 1| 2| 3| 4*
* B| | | * | | | * | | | * | |N=|N=* | | | * | | | * B| B| B| B* B| B| B| B*
* L| | | * | | | * | | | * | |18|00* |N=|N=|N=*N=|N=|N=|N=* | | | * | | | *
* | | | * | | | * | | | * | | | * |96|08|08*24|24|64|64*N=|N=| | *N=|N=| | *
* 2| | | * | | | * | | | * | | | * | | | * | | | *00|18| | *00|18| | *
* | | | * | | | * | | | * | | | * | | | * | | | * | | | * | | | *
*************************************************************************************************
The TTL IO BUS consists of three cables, numbered 1, 2, and 3. The pinout
on the cables are in the drawings, but for your reference, here it is:
Note that each cable is actually 2 26-conductor flat cables. It is only
logically cables 1, 2, and 3. In the drawings, you will see them numbered
1 to 5. (The 3rd logical cable only has 1 physical cable). In general,
wire 1 of each physical cable is the wire with the red stripe, but you
better check to make sure! Data is only on the odd-numbered wires. Even
numbered wires are grounded.
LOGICAL CABLE 1
PHYSICAL
CABLE WIRE PIN NAME COMMENT
---------------------------------------------------------------------------
1 1 AC1 ¬TTL IOB 00 Bidirectional, low-true data bus
1 3 AD1 ¬TTL IOB 01
1 5 AE1 ¬TTL IOB 02
1 7 AF1 ¬TTL IOB 03
1 9 AH1 ¬TTL IOB 04
1 11 AJ1 ¬TTL IOB 05
1 13 AK1 ¬TTL IOB 06
1 15 AL1 ¬TTL IOB 07
1 17 AM1 ¬TTL IOB 08
1 19 AN1 ¬TTL IOB 09
1 21 AP1 ¬TTL IOB 10
1 23 AR1 ¬TTL IOB 11
3 1 AD2 ¬TTL IOB 24
3 3 AE2 ¬TTL IOB 25
3 5 AF2 ¬TTL IOB 26
3 7 AH2 ¬TTL IOB 27
3 9 AJ2 ¬TTL IOB 28
3 11 AK2 ¬TTL IOB 29
3 13 AL2 ¬TTL IOB 30
3 15 AM2 ¬TTL IOB 31
3 17 AN2 ¬TTL IOB 32
3 19 AP2 ¬TTL IOB 33
3 21 AR2 ¬TTL IOB 34
3 23 AS2 ¬TTL IOB 35
3 25 AT2 ¬TTL I/O RESET
LOGICAL CABLE 2
PHYSICAL
CABLE WIRE PIN NAME COMMENT
---------------------------------------------------------------------------
2 1 AC1 ¬TTL IOB 12 Bidirectional, low-true data bus
2 3 AD1 ¬TTL IOB 13
2 5 AE1 ¬TTL IOB 14
2 7 AF1 ¬TTL IOB 15
2 9 AH1 ¬TTL IOB 16
2 11 AJ1 ¬TTL IOB 17
2 13 AK1 ¬TTL IOB 18
2 15 AL1 ¬TTL IOB 19
2 17 AM1 ¬TTL IOB 20
2 19 AN1 ¬TTL IOB 21
2 21 AP1 ¬TTL IOB 22
2 23 AR1 ¬TTL IOB 23
4 1 AD2 ¬TTL IOS3(1)
4 3 AE2 ¬TTL IOS4(1)
4 5 AF2 ¬TTL IOS5(1)
4 7 AH2 ¬TTL IOS6(1)
4 9 AJ2 ¬TTL IOS7(1)
4 11 AK2 ¬TTL IOS8(1)
4 13 AL2 ¬TTL IOS9(1)
4 15 AM2 ¬TTL DATAO CLR
4 17 AN2 ¬TTL DATAO SET
4 19 AP2 ¬TTL DATAI
4 21 AR2 ¬TTL CONO CLR
4 23 AS2 ¬TTL CONO SET
4 25 AT2 ¬TTL CONI
LOGICAL CABLE 3
PHYSICAL
CABLE WIRE PIN NAME COMMENT
---------------------------------------------------------------------------
5 1 AC1 ¬TTL PI1 Interrupt request lines
5 5 AE1 ¬TTL PI2
5 9 AH1 ¬TTL PI3
5 13 AK1 ¬TTL PI4
5 17 AM1 ¬TTL PI5
5 21 AP1 ¬TTL PI6
5 25 AS1 ¬TTL PI7
UML - TTL IO BUS EXTENSION
With the TTL IO BUS Extension, the TTL IO BUS comes through in slots 1, 2, and 3.
The buffer cards are in slots 4 and 5. The control card is in slot 6. Thereafter,
the bits come out on the B row, low order bits on even slots, high order bits
on odd slots, starting at B08.
AB06, the control card, has 8 devices selected already. These come out on
pins along with their current assignments as follows:
IO BUS EXTENSION DEVICE SELECT (LOW-TRUE)
DEVICE PIN CURRENT ASSIGNMENT
---------------------------------------------------------------------------
340 AL1 FRM Interface, both input and output sides
344 AM1 10/6 Interface, both input and output sides
350 AN1 (currently unnasigned)
354 AP1 (currently unnasigned)
360 AR1 Paralyzer
364 AS1 (currently unnasigned)
370 AU1 (currently unnasigned)
374 AV1 (currently unnasigned)
TTL IO BUS EXTENSION
*************************************************************************************************
* 1| 2| 3| 4* 5| 6| 7| 8* 9|10|11|12*13|14|15|16*17|18|19|20*21|22|23|24*25|26|27|28*29|30|31|32*
* | | | * | | | * | | | * | | | * | | | * | | | * | | | * | | | *
* T| T| T|R1* R|R2| |10*10|10|10|10*10| P| P| P* | F| F| F* F| F| F| * | | | * | | | *
* T| T| T| * | | |/6*/6|/6|/6|/6*/6| A| A| A* | R| R| R* R| R| R| * | | | * | | | *
* L| L| L|N=*N=| C| | * | | | * | R| R| R* | M| M| M* M| M| M| * | | | * | | | *
* | | |00*18| T| | I* I| I| C| C* C| A| A| A* | | | * | | | * | | | * | | | *
* C| C| C| * | L| | N* N| N| B| B* B| | | * | I| I| I* C| C| C| * | | | * | | | *
* B| B| B| D* D| | | T* T| T| L| L* L| 1| 2| C* | N| N| N* B| B| B| * | | | * | | | *
* L| L| L| A* A| | | * | | | * | | | B* | T| T| T* L| L| L| * | | | * | | | *
* | | | T* T| | | 1* 2| 3| 1| 2* 3| | | L* | | | * | | | * | | | * | | | *
* 1| 2| 3| A* A| | | * | | | * | | | * | 1| 2| 3* 1| 2| 3| * | | | * | | | *
* | | | * | | | * | | | * | | | * | | | * | | | * | | | * | | | *
*************************************************************************************************
* 1| 2| 3| 4* 5| 6| 7| 8* 9|10|11|12*13|14|15|16*17|18|19|20*21|22|23|24*25|26|27|28*29|30|31|32*
* | | | * | | | * | | | * | | | * | | | * | | | * | | | * | | | *
* T| T| T|R1* R|R2| |10*10|10| | * | P| P| * | F| F| F* | | | * | | | * | | | *
* T| T| T| * | | |/6*/6|/6| | * | A| A| * | R| R| R* | | | * | | | * | | | *
* L| L| L|N=*N=| C| | * | | | * | R| R| * | M| M| M* | | | * | | | * | | | *
* | | |00*18| T| | I* I| I| | * | A| A| * | | | * | | | * | | | * | | | *
* C| C| C| * | L| | N* N| N| | * | | | * | I| I| I* | | | * | | | * | | | *
* B| B| B| D* D| | | T* T| T| | * | 1| 2| * | N| N| N* | | | * | | | * | | | *
* L| L| L| A* A| | | * | | | * | | | * | T| T| T* | | | * | | | * | | | *
* | | | T* T| | | 1* 2| 3| | * | | | * | | | * | | | * | | | * | | | *
* 1| 2| 3| A* A| | | * | | | * | | | * | 1| 2| 3* | | | * | | | * | | | *
* | | | * | | | * | | | * | | | * | | | * | | | * | | | * | | | *
*************************************************************************************************
UML DAC/ADC
The DAC and the ADC interface are on a single rack. The TTL IO bus goes through
the rack in the middle with the ADC being in the higher numbered slots and
the DAC being in the lower numbered slots. The DAC and the ADC themselves are
physically located elsewhere, with the bits being transferred through flat cables.
There are four cables: two for the ADC and two for the DAC. Through these are
transferred the 16 data bits, filter select, and channel select, along with
some control information.
DAC/ADC
*************************************************************************************************
*A1|A2|A3|A4*A5|A6|A7|A8*A9|10|11|12*13|14|15|16*17|18|19|20*21|22|23|24*25|26|27|28*29|30|31|32*
* | | | * | | | * | | | * | | | * | | | * | | | * | | | * | | | *
* | | D| D* D| D| D| D* D| D| D| C* T| T| T| A* A| A| A| A* A| | | * | | | * | | | *
* | | A| A* A| A| A| A* A| A| A| R* T| T| T| D* D| D| D| D* D| | | * | | | * | | | *
* | | C| C* C| C| C| C* C| C| C| O* L| L| L| C* C| C| C| C* C| | | * | | | * | | | *
* | | | * | | | * | | | C* | | | * | | | * | | | * | | | * | | | *
* | | C| C* F| O| C| C* B| B| B| K* C| C| C| B* B| P| C| C* C| | | * | | | * | | | *
* | | N| N* L| U| B| N* U| U| U| * B| B| B| U* U| A| B| N* N| | | * | | | * | | | *
* | | T| T* O| T| L| T* F| F| F| * L| L| L| F* F| C| L| T* T| | | * | | | * | | | *
* | | R| R* A| | | R* | | | * | | | * | K| | R* R| | | * | | | * | | | *
* | | L| L* | | | L* | | | * 1| 2| 3| * | | | L* L| | | * | | | * | | | *
* | | | * | | | * | | | * | | | * | | | * | | | * | | | * | | | *
*************************************************************************************************
*B1|B2|B3|B4*B5|B6|B7|B8*B9|10|11|12*13|14|15|16*17|18|19|20*21|22|23|24*25|26|27|28*29|30|31|32*
* | | | * | | | * | | | * | | | * | | | * | | | * | | | * | | | *
* | | D| D* D| D| D| D* D| D| D| C* T| T| T| A* A| A| A| A* A| | | * | | | * | | | *
* | | A| A* A| A| A| A* A| A| A| R* T| T| T| D* D| D| D| D* D| | | * | | | * | | | *
* | | C| C* C| C| C| C* C| C| C| O* L| L| L| C* C| C| C| C* C| | | * | | | * | | | *
* | | | * | | | * | | | C* | | | * | | | * | | | * | | | * | | | *
* | | C| C* F| O| C| C* B| B| B| K* C| C| C| B* B| P| C| C* C| | | * | | | * | | | *
* | | N| N* L| U| B| N* U| U| U| * B| B| B| U* U| A| B| N* N| | | * | | | * | | | *
* | | T| T* O| T| L| T* F| F| F| * L| L| L| F* F| C| L| T* T| | | * | | | * | | | *
* | | R| R* A| | | R* | | | * | | | * | K| | R* R| | | * | | | * | | | *
* | | L| L* | | | L* | | | * 1| 2| 3| * | | | L* L| | | * | | | * | | | *
* | | | * | | | * | | | * | | | * | | | * | | | * | | | * | | | *
*************************************************************************************************
CABLE BITS
CABLE WIRE PIN NAME COMMENT
---------------------------------------------------------------------------
A7 1 AC1 LINCLR MRCLR buffered
A7 3 AD1 ¬GO Clocks input register on DAC
A7 5 AE1 ¬SAMP1 Channel 1 Sample-hold trigger
A7 7 AF1 ¬SAMP2 Channel 2 Sample-hold trigger
A7 9 AH1 ¬SAMP3 Channel 3 Sample-hold trigger
A7 11 AJ1 ¬SAMP4 Channel 4 Sample-hold trigger
A7 13 AK1 ¬FIL0 Filter select, low-order bit
A7 15 AL1 ¬FIL1 Filter select, high-order bit
A7 17 AM1 ¬OUT0 High order data bit
A7 19 AN1 ¬OUT1
A7 21 AP1 ¬OUT2
A7 23 AR1 ¬OUT3
A7 25 AS1 ¬OUT4
B7 1 AC1 ¬OUT5
B7 3 AD1 ¬OUT6
B7 5 AE1 ¬OUT7
B7 7 AF1 ¬OUT8
B7 9 AH1 ¬OUT9
B7 11 AJ1 ¬OUT10
B7 13 AK1 ¬OUT11
B7 15 AL1 ¬OUT12
B7 17 AM1 ¬OUT13
B7 19 AN1 ¬OUT14
B7 21 AP1 ¬OUT15
B7 23 AR1 ¬ADSEL0 Unimplimented AD select bits
B7 25 AS1 ¬ADSEL1 Unimplimented AD select bits
A19 1 AC1 ¬CHNSEL1 AD Channel select
A19 3 AD1 ¬CHNSEL2 AD Channel select
A19 5 AE1 ¬CHNSEL3 AD Channel select
A19 7 AF1 ¬CHNSEL4 AD Channel select
A19 9 AH1 ¬SAMPLE Sample-hold trigger
A19 11 AJ1 CONVERT ADC trigger
A19 13 AK1 ¬MPX Selects alternate inputs
A19 15 AL1 ¬FILSEL0 AD Filter select
A19 17 AM1 ¬FILSEL1 AD Filter select
A19 19 AN1 ¬FILSEL2 AD Filter select
A19 21 AP1 ¬FILSEL3 AD Filter select
A19 23 AR1 ADSEL2 Unimplimented select bits
A19 25 AS1 A/D13 Low order bit
B19 1 AC1 A/D0
B19 3 AD1 A/D1
B19 5 AE1 A/D2
B19 7 AF1 A/D3
B19 9 AH1 A/D4
B19 11 AJ1 A/D5
B19 13 AK1 A/D6
B19 15 AL1 A/D7
B19 17 AM1 A/D8
B19 19 AN1 A/D9
B19 21 AP1 A/D10
B19 23 AR1 A/D11
B19 25 AS1 A/D12
CABLING
There are a large number of audio and digital cables running between the
computer room and the music lab. Some of the digital cables,
unfortunately, renumber themselves several times in a given run.
MACHINE MUSIC
ROOM SPINE LAB USE
----------------------------------------------------------------------------------
66 1 25 DD36 audio switch connection
33 2 2 TTY16 Read (from EIA connector for loading KIM)
64 3 26 DD36 serial data line (to card in bay w. 10/11 int)
65 4 25 DD36 (video bay #16) video
28 28 28 DD77 (video bay #57) video
29 29 29 DD77 audio switch connection (not implemented yet)
105 105 105 KIM PDP-6 "ready" signal (to KIM rack marked "6")
107 107 107 TTY16 Write (to EIA connector for loading KIM)
108 108 108 KIM serial data line (from 6 IOB EXT to KIM "out")
109 109 109 KIM PDP-10 "ready" (from 10 IOB EXT to KIM "10")
This list is not quite complete as yet.